Non-python (for example deb) dependencies

[KOLANICH]

I wonder if it is possible to declare non-python dependencies.

I mean that certain packages are installed better when the lib is already present in system, so it'd be nice to have a way to put into the manifest the info about needed packages from system package manager.

Unfortunately we need a shared name for them all, so we need some remapping common-name -> distro-specific common name. I remember that I have seen in some installers such kind of mapper, but imho embedding this info into an installer would be a mess since this list must be updated. The maintsiners of this list also should take into account compatible alternatives. So I propose to make repo owners compose this list.
I mean, that for example in Ubuntu there are 4 default repos. For each repo a special package with the name of certain format, for example python-os-packages-remapping-.+ and no dependencies should exist.
These packages should dump an sqlite DB of known format somewhere and register location of that DB with setuptools.
A new format of dependency should be introduced, like
qt;os_package
.
When used, setuptools and pip look up the distro-specific name in the registry and then using that name, check if installed, check version and request installation if needed.

[pganssle]

I don't see any way for us to do this, and I don't think it's within the scope of setuptools.

@ncoghlan @dstufft @di I know this is an ongoing issue with the packaging landscape, do we have a canonical place for the discussion?

[di]

Not that I know of. The right place for this issue is probably at https://github.com/pypa/packaging-problems/issues

[pganssle]

OK, I'll close this one. If someone creates a new issue for it in packaging-problems, we can put a link here.

[ncoghlan]

Existing issues/discussions:

• improving error messages for missing external deps (which requires expressing what they are in a way that installers can read): Better error messages when a external dependency isn't found packaging-problems#27
• @tleeuwenburg's old draft PEP at Adding the draft status PEP for external dependency expression interoperability-peps#30 (not usable as is - there are enough tools/libraries that parse the existing dependency declaration format that adding a new field or fields is likely to be more compatible than reusing any of the existing ones)

The ticket for reporting missing external dependencies at install time is likely the place to start, since it adds the requirement for publishers to be able to either express or infer those dependencies, without automatically adding the requirement to implicitly resolve them.