Comments (9)
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.
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.
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.
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.
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.
Perhaps we can add a commented line for python_requires?
from sampleproject.
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.
+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.
+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)
- swift_apple(swift-module-elseTests) HOT 1
- Where to save tar.gz file
- code execution backdoor HOT 2
- stock_tokens list returns TypeError: can only concatenate str (not "list") to str HOT 2
- Delay of approx 20 seconds HOT 1
- UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 3342: character maps to <undefined> HOT 1
- packet queue is empty, aborting HOT 2
- How do you test this? HOT 2
- Tools
- How to include non python configuration files HOT 1
- How to control spelling incorrection even if phonetically sound same HOT 1
- pyproject.toml: references a "python_requires" key that does not exist HOT 2
- help! Executing file is not working HOT 2
- sampleproject doesn't include files `setup.py` and `setup.cfg` (and maybe other) one of the latest published guides claims it should have HOT 1
- Unclear description of "readme" field in pyproject.toml HOT 2
- The package name HOT 3
- TypeError: unhashable type: 'dict' HOT 4
- Should development dependencies be included in the optional section?
- Error in documentation regarding Packaging and Distributing projects using Setuptools
- Stop advertising adding `wheel` as an unconditional PEP 517 build dependency HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sampleproject.