Comments (19)
Given PEP 621, we might want to skip setup.cfg
and move towards pyproject.toml
as described in that PEP instead.
from sampleproject.
Ironically, now that PEP 517 is available, using setuptools at all is no longer as uncontroversial as it once was - for simple projects flit
is arguably a better choice.
IMO the strongest argument for not switching sampleproject to use setup.cfg
is that so few setuptools-using projects have actually done so already. In my view sampleproject should be following trends, not setting them.
from sampleproject.
I stand corrected, the blog post that I mentioned does not work at all.
from sampleproject.
The packaging tutorial authors are currently debating how to incorporate PEP 621 in the docs. It's possible that rather than simply using setuptools with pyproject.toml
, they may decide to use a different backend altogether (flit or hatch, for example).
As the main purpose of this project is to be an example of what the packaging guide recommends, we should wait for their decision and follow that.
from sampleproject.
It happened in v30.3.0. I was cautious to announce it because it's the kind of feature that everyone would want to adopt, but would not be available until most deployments had a late version of setuptools available. As we're 9 months in now, perhaps it's widespread enough to recommend it in a project such as this one. I personally haven't used it, so I'd like to hear from others who have before recommending it.
from sampleproject.
OK, cool. Over on the PUG issue, @dstufft mentioned possible problems with RTD (I don't know the details). And it will of course cause issues for people building from source with older versions of setuptools - that's always going to be a problem with new setuptools features, but I have no feel for upgrade rates.
from sampleproject.
See the discussion in pypa/packaging.python.org#378 - basically I've been persuaded that using setup.cfg
probably isn't something we should be recommending in the PUG at this point.
from sampleproject.
Has the wisdom arrived at in these threads changed over the last two years? Do we have any idea what the prevelance of versions >= 30.3.0 might be?
I'm very keen to drop any reference to distutils
in my packages, include install_requires=['setuptools>=30.3.0']
and steam forward with migrating metadata into setup.cfg. I don't necessarily have the same problem with random users doing an install from sdist
distributions since I target the Raspberry Pi platform almost exclusively, but I've nonetheless found what appears to be a sensible trap for this edge-case.
It also looks like pip is capable of parsing install_requires
before executing the package install and invoking setuptools
(if and when this even happens during a .whl install I'm not totally sure) so adding setuptools
to install_requires
appears to me to be a sensible approach that will slowly march the userbase forward.
Here's the pattern that I've arrived at: https://github.com/pimoroni/boilerplate-python/blob/master/library/setup.py
from sampleproject.
@Gadgetoid You can do this in your own project without issues. The constraints on an "official recommendation" like the PyPA sample project are significantly different than those that apply to individual user projects.
Having said that, I think this could probably do with being revisited for sampleproject. 2 years is plenty of time for the relevant setuptools features to become mainstream.
from sampleproject.
@pfmoore thank you. I'm keenly aware that "just because I can, doesn't mean I should" and want to at least make somewhat informed decisions (since I'm shipping dozens of libraries and perhaps indirectly influencing how beginners might approach writing their own), so your feedback is appreciated.
from sampleproject.
In general, sampleproject is looking to make recommendations when they are
- Uncontroversial
- Pretty much the one-true-way-to-do-X (e.g, not making a advertisement for one testing framework over another, or poetry over pipenv, etc; at least while there is healthy competition amongst approaches which pypa doesn't want to bias)
- Safe and will work for the vast vast majority of users with their existing software
- Not subject to change in the near future
So that a beginner can copy-paste what's here, edit specifics to their project, and be practically 100% sure it will work. Since there are many warts and alternatives in different parts of the packaging ecosystem, we tend to want to stray away from parts where we might recommend X but then Y becomes the better things N months in the future. Play it safe.
One small issue I've always had with setup.cfg I've always had is that originally it was not intended to be a distributed-with-the-package file at all, but a file you could add into to a source distribution you'd downloaded to customise how it built1 (e.g on a per-system basis - look for libraries here on my particular computer). Then IIRC pbr decided it could take over that functionality to be used as a packaging description file (contradicting the above functionality) without any consultation. And then it's been dragged in that direction ever since, but without ever bothering to definitely resolve this issue.
Small note from the pyproject.toml PEP discussing it as well
from sampleproject.
According to this blog post it seems like you can have the metadata in the pyproject.toml file itself without any issues. If that is possible I think it would be a good idea to reflect that in the project > https://martin-thoma.com/pyproject-toml/
from sampleproject.
Reviving this, since the packaging tutorial (which references this repo) now recommends setup.cfg
. Would the maintainers accept a PR for this? There's already #57 and #96, but I'm guessing those need some work.
Given PEP 621, we might want to skip
setup.cfg
and move towardspyproject.toml
as described in that PEP instead.
Looks like that's not supported in setuptools (yet): pypa/setuptools#2671
According to this blog post it seems like you can have the metadata in the pyproject.toml file itself without any issues.
@jonathan-s I don't think the pyproject.toml
in that blog post is valid; it seems to be mixing Poetry-style metadata
and dependencies
configuration with a setuptools build-system
.
from sampleproject.
I know it's been more than a year, but I think my previous comment still stands: if we're going to standardize around PEP 621 (and we should) then let's not introduce extra churn here by changing the recommendation twice.
from sampleproject.
Generally I'm +1 on that, but setuptools apparently has resource issues which mean it might be some time before they have PEP 621 support, and recommending an approach that's at least declarative in the interim would be an improvement. (The alternative is to switch to flit as the recommended "beginner" approach, although the way it uses VCS metadata might be astumbling block for new users).
from sampleproject.
from sampleproject.
Fast forward to 2022, setuptools 61.0.0 actually has experimental support for project metadata in pyproject.toml
w.r.t PEP621
from sampleproject.
See Removing setup.cfg and setup.py from the packaging tutorial - Packaging - Discussions on Python.org
from sampleproject.
See also #166, which is a draft PR implementing this repo's move to pyproject.toml
, blocked on setuptools supporting editable installs (and/or a decision on a different backend to recommend).
from sampleproject.
Related Issues (20)
- 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
- Should PyPUG editors have access to this project? HOT 3
- Remove Python version 3.7 to unblock tests HOT 1
- Update tox version? And tox best practices? HOT 2
- Sample build breaks if LICENSE.txt file contains GPL2 license text (containing 0x0c) HOT 13
- Flake8 configuration should not use select
- pyproject.toml file don't mention anything about the compatible platforms allowed by Wheel?
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.