Private registries through pyproject.toml

[ginwakeup]

Hello,

I was wondering if there's a way to specify a private registry through the pyproject.toml

Poetry can do it with:

[[tool.poetry.source]]
name = "private"
url = "http://example.com/simple"

And I was wondering why setuptools doesn't offer something similar?

In complex pipelines with multiple private registries this is a bit of a pain to setup, and it would be really useful to be able to specify the private registry in the pyproject.toml.

We do not really want to have to ask developers to set their PIP registries by themselves if possible.

[abravalheri]

The gist of "why setuptools doesn't offer something similar?" is the following:

The setuptools project aims to offer a Python package backend as specified in the PEP 517 standard.

As a project backend, setuptools focuses in building modules/packages and bundling them in distributable formats like sdist and wheels.

This means that setuptools is not involved in the process of dependency resolution or dependency installation.

Therefore, dealing with Python indexes is outside of the scope of the project.

In the case of Poetry, things is different. Poetry is not only a build backend, but rather accumulates several roles/objectives, e.g. providing a build backend, doing dependency resolution and installation, managing environments, etc... It makes sense for Poetry to have such features.

---

Getting back to your question... There might be a way, but it is not via setuptools, considering that dealing with indexes and installing dependencies is outside of the scope of the project.

[ginwakeup]

As a project backend, setuptools focuses in building modules/packages and bundling them in distributable formats like sdist and wheels.

Yes, indeed. Building packages might require extra dependencies that live in different private registries, how do I deal with that? Based on your reply, I guess I should have the build environment read prior to run setuptools?
Unless I am missing something, this sounds like setuptools is indeed missing a feature, as it's not able to build a package that uses dependencies from different registries than pypi.

In addition to that, this was previously supported by dependency_links in setuptools which has been removed after pip removed support for it.

[abravalheri]

Please note that setuptools does not install the build dependencies either. This is the role of the build frontend according to PEP 517, which is also outside of the scope of setuptools. A build backend just compile and bundles files, it is not within its responsibilities to deal with the dependencies.

Previously setuptools had support for stuff like dependency_links, but that was because setuptools included easy_install and had a different scope. The ecosystem was also very different from what it is right now... With the changes in the ecosystem and setuptools deprecating easy_install and working actively for its removal of the project, the scope was reduced.

If you are concerned with build time dependencies the best place to look for how they are resolved is in the build frontend. If you are concerned with runtime dependencies the best place to look for how they are resolved is in the package installer. If a tool (like poetry) cover all these roles togheter then maybe it can also offer support for such a feature.