-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion: support for pyproject.toml configuration #1688
Comments
I'd prefer option 1. I imagine during the deprecation period that the setup.cfg documentation could be removed, but a permalink to the old documentation made available for projects still relying on that technique. One way to ease the transition could be for the My second choice would be option 3. I'd really like to avoid supporting multiple formats that do essentially the same thing. Another consideration I'd like to mention is the proposal I only recently started fleshing out in pypa/packaging-problems#248. Such an approach would be yet another declarative format. However, this proposed approach would enable project developers to supply metadata decoratively in the canonical format (or in a format suitable for the requisite build steps). If such an approach is deemed viable and comes to fruition, the value in migrating to pyproject.toml may prove small. I suggest postponing this transition at least until that more ambitious proposal is disposed or reaches fruition. |
I'm pretty sure the deprecation period would be literally forever. I bet there are projects on PyPI that (a) are dead and will never see another release, (b) are still used, and (c) depend on setup.cfg to install. I'm not opposed to adding features to setuptools and better ways to do things, but I think it's about 100x less important than not breaking stuff. |
I'm in favour of 1, with deprecated forever status (ideally keep the heading in documentation and just remove all the content, replacing it with a paragraph saying use pyproject.toml) |
There is an ETA for this? Or there is still some discussion pending?.I think that Option 1 is the best, but here is not stated for sure if this will be done. |
@qlixed There is no ETA. I think we probably have a rough consensus for Option 1 with an indefinite deprecation period (we don't have to specify the length of the deprecation period anyway). I won't have time to do this any time soon, but I think we can accept a contribution that does. I think we'll need to:
I think we can say that if options are specified in both We'll also need to decide how to handle the little ad-hoc "types" we've implemented like |
Yes, TOML supports both nested and inline tables. For example, the version could be hardcoded as a string: version = "0.0.0" ... or it could be a table specifying one of version = { attr = "setuptools.version" } The same 'trick' is used by Poetry to separate dependency markers from version specifiers. |
In the fundable packaging improvements list I summarized this as follows (if it's inaccurate, I'd appreciate a correction, especially as a pull request):
I'd also like to better work out what this entails and how long it would take. To dig into @pganssle's proposed sequence:
Would this live within setuptools or be part of some other codebase?
One subtask being: decide and implement how to deal with it if people use Also: should this task include implementing a deprecation notices to output when the user's supplied a So that's the backend development work. I'd add in:
What have I missed or gotten wrong? Is this mostly right? |
The current documentation regarding `pyproject.toml` claims that support for using it to specify package metadata and build configuration options might be "completely removed" in a future release. However, nowadays it is clear (pypa#1688 (comment) and pypa#3214) that `pyproject.toml` is not going anywhere, is here to stay, and is in fact expected to be the preferred format in the future. This makes an incremental change toward that future by clarifying that `pyproject.toml` support will not be removed in a future release of setuptools.
Over the last few months, I've been using
setup.cfg
more, and I find the syntax and types and such to be super counter-intuitive. I don't find TOML to be a breeze per se, but it's at least a lot clearer to me how to specify a string, a list, etc. We also hear a lot of cries to move towards supportingpyproject.toml
as the "one file" for setup configuration, in favor ofsetup.cfg
. I'm not terribly opposed to this, but I want to open up the discussion for a few options:pyproject.toml
as the one true way to do declarative builds, moving allsetuptools
configuration over there and deprecatingsetup.cfg
(partially what is discussed in Merge setup.cfg spec with pyproject.toml one and deprecate setup.py and setup.cfg #1160, and if we decide on that option we can move over to that issue).pyproject.toml
as a second supported way to do a declarative configuration, alongsidesetup.cfg
.setup.cfg
indefinitely.I am deeply concerned with the large amount of churn that we're introducing into the Python packaging space, so I don't want to make a lot of changes for the sake of changes, but I do think that at least having the option to use a
pyproject.toml
would be a real benefit, so I'm basically in favor of option 2.I think the biggest downside of option 2 is that it means maintaining, testing and documenting three separate locations for all of our options - how to do it in
setup.cfg
, how to do it inpyproject.toml
, and how to do it insetup.py
. I think the hard part is going from 1 way to do everything to 2 ways. Our documentation is a mess anyway, but my beautiful vision for the future is that all our examples have "tabs" that allow you to toggle them betweensetup.cfg
andsetup.py
. Adding apyproject.toml
in there would probably not be the worst thing.The text was updated successfully, but these errors were encountered: