Git Product home page Git Product logo

Comments (9)

pfmoore avatar pfmoore commented on July 21, 2024

I'd be very cautious how we present this (if we do). It's very important not to encourage over-specifying here, or we'll end up with well-meaning project authors listing the versions they support (e.g., 2.7, 3.5 and 3.6), and as a result locking users out from testing their package with newer versions of Python, or even using untested combinations (which they might need to do, accepting that it's at their own risk).

I don't have much of a problem with requires_python >= 3 but anything more restrictive should be used with care (even requires_python = 3 runs a risk if & when Python 4 gets released!).

from sampleproject.

ncraike avatar ncraike commented on July 21, 2024

I understand that concern.

Considering the goal of sampleproject is to demo packaging tools to new Python developers and get them shipping their code, I think many if not most will be packaging young projects where requires_python >= 3 is appropriate. A single codebase installable on both Python 2 and 3 is not an an easy task and not a beginner's problem.

My biggest concern though is that the current sample setup.py seems to present a solution to packaging a Python-3-only project with the sample usage of "classifiers"… but is not actually a solution at all.

I think a sample usage of requires_python would go a long way to clarifying which options solve which problems. But it'd definitely make sense if the example was commented out by default, and if there was plenty of supporting comments explaining why, eg requires_python >= 3 may be what they need, but requires_python = 3.3 is likely a bad idea.

from sampleproject.

pfmoore avatar pfmoore commented on July 21, 2024

That's a fair comment. The current project, though, does take pains to be an example of how to write a 2/3 compatible project, for better or worse (tox.ini includes 2.7, setup.py includes 2.7 in the classifiers, etc).

A comment block in setup.py including example usage of requires_python could be useful, but that block should probably note the other things that need to change, too. And that might make it too clumsy.

Maybe this is something that should be explained in the Packaging User Guide, rather than trying to cram everything into comments in here.

from sampleproject.

ncraike avatar ncraike commented on July 21, 2024

The current project, though, does take pains to be an example of how to write a 2/3 compatible project, for better or worse (tox.ini includes 2.7, setup.py includes 2.7 in the classifiers, etc).

Ah, right. If that's the current standard you're aiming for, I completely get you not wanting to abandon that and assume Python3-only.

Maybe this is something that should be explained in the Packaging User Guide, rather than trying to cram everything into comments in here.

That's a decent point. I'm worried that the absence of requires_python altogether makes the classifiers look like they control the same Pip install behaviour. New developers won't read into other options in the Packaging User Guide if they think they've already found the option they need.

Of course we can't ensure that 100% of developers read the relevant docs when they need to. But I think the current state increases the risk they'll make the same mistake I did.

from sampleproject.

marcelm avatar marcelm commented on July 21, 2024

To anyone who stumbles upon this issue trying to figure out how to use python_requires (and whether requires_ or python_ comes first), here is how it should look in setup.py for a Python-3-only project:

setup(
    ...
    python_requires='>=3',
    ...
)

from sampleproject.

pradyunsg avatar pradyunsg commented on July 21, 2024

Perhaps we can add a commented line for python_requires?

from sampleproject.

xavfernandez avatar xavfernandez commented on July 21, 2024

With Python 2 support ending in less than a year, I think defaulting to python_requires='>=3' would make sense.
(And with Python 3.4 support ending in less than 3 months, we might even push it to python_requires='>=3.5')

from sampleproject.

pfmoore avatar pfmoore commented on July 21, 2024

+1 on making 3.5+ the norm:

setup(
    ...
    # Remove or modify this line if you want to support Python versions older than 3.5
    python_requires='>=3.5',
    ...
)```

from sampleproject.

f18m avatar f18m commented on July 21, 2024

+1 for this issue... I just released my Python3-only package on pypi just tagging it with the classifier "Programming Language :: Python :: 3" and a lot of users complained that it didn't work after installing it with "pip" instead of "pip3"...
I'm going to add the
python_requires='>=3',
line to setup.py, but having that in the example would have saved me a lot of time! Thanks.

from sampleproject.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.