Skip to content
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

Add clarifications about experimental status for pyproject.toml configuration #3347

Merged
merged 7 commits into from Jun 17, 2022

Conversation

abravalheri
Copy link
Contributor

As noted in #2671 (comment), it would be good if we clarify which parts of the pyproject.toml configuration are considered experimental or not.

It is been a few months since the implementation of PEP 621 support landed in setuptools (after a long period of feedback), and it seems now that support for project metadata in pyproject.toml has stabilised. Moreover the existing implementation is backed by a PEP, therefore it makes sense to consider this part of the feature stable.

Summary of changes

  • Warn about tool.setuptools instead of project metadata in pyproject.toml

Closes

Pull Request Checklist

docs/userguide/datafiles.rst Outdated Show resolved Hide resolved
docs/userguide/package_discovery.rst Outdated Show resolved Hide resolved
docs/userguide/quickstart.rst Outdated Show resolved Hide resolved
@abravalheri abravalheri merged commit 9ae9334 into pypa:main Jun 17, 2022
@abravalheri abravalheri deleted the clarify-experimentality branch June 17, 2022 15:41
@EwoutH
Copy link

EwoutH commented Oct 10, 2022

Would it be time to also remove the beta status of dependencies and optional-dependencies in pyproject.toml? It also has been in for a long term and is widely used, and is backed by the same PEP 621.

@abravalheri
Copy link
Contributor Author

Hi @EwoutH thank you very much for bringing this to our attention. dependecies and optional-dependencies should be stable by now. Have I forgotten to remove a warning or something in the docs? Could you please point me out to the location you found this information so I can have a look?

@EwoutH
Copy link

EwoutH commented Oct 10, 2022

Thanks for getting back so quickly! In the table in the Dynamic Metadata section of the Configuring setuptools using pyproject.toml files documentation, dependencies and optional-dependencies are still listed as beta.

But I might have read it wrong, it means that using files for those is still in beta, and that might be correct?

In any case, if that's not in beta anymore, I opened a PR to remove them in #3632.

@abravalheri
Copy link
Contributor Author

But I might have read it wrong, it means that using files for those is still in beta, and that might be correct?

That is the case. The beta status is for using [tool.setuptools.dynamic] for dependencies and optional-dependencies with file:.

In any case, if that's not in beta anymore, I opened a PR

I would keep the beta for a little longer, since we did not receive a lot of feedback about this feature yet.

@EwoutH
Copy link

EwoutH commented Oct 10, 2022

Thanks for the explanation!

I had one other remark. One very useful feature I found when defining optional-dependencies, it that you not only can list packages, but also optional dependencies of packages. This way you can also define a optional dependency that combines your own optional dependencies, for example an [all] extra like below:

[project.optional-dependencies]
dev = ["pytest", "pytest-mock", "jupyter_client", "ipyparallel"]
cov = ["pytest-cov", "coverage", "coveralls"]
docs = ["sphinx", "nbsphinx", "myst", "pyscaffold", "myst-parser"]
graph = ["altair", "pydot", "graphviz"]

all = ["your-package[dev,cov,docs,graph]"]

However, this feature is a bit hidden. What would be a good place to add this to the docs?

@abravalheri
Copy link
Contributor Author

abravalheri commented Oct 10, 2022

I believe this is pip-specific, isn't it? (I don't know if other frontends support self-referential dependencies).

It seems that the community has been asking for this for a while. It might make sense to discuss this in the context of standardization first (in the Python Packaging discourse).

@EwoutH
Copy link

EwoutH commented Oct 11, 2022

That's a very good idea. I don't know if I have the skill and time to write a structured proposal for this however. Probably useful to have someone from pip involved as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants