What is Install-Paths-To in WHEEL file?

[pf_moore (Paul Moore)]

@steve.dower

Only as far as the Lib\site-packages subdirectory and Scripts/bin. That doesn’t help with any of the other paths people want Install-Paths-To to define.

venv.EnvBuilder.ensure_directories() returns a context object that contains the inc_path (include files), lib_path (purelib) and bin_path (scripts) directories. And sysconfig does return values for data files and headers for a venv. Admittedly, the header location seems to be in the base install, and I don’t know either why that’s useful or why it’s not the same as venv, but it’s definitely present.

For my purposes, though, and for the purposes of this thread (or at least this issue raised in the thread), what’s actually needed is a definitive list of what destination directory keys are valid in a wheel, and what directories they should correspond to in the current interpreter environment. And that list needs to be discoverable by applications that have no access to anything but the core interpreter and stdlib, for bootstrapping purposes.

Sysconfig seems the “obvious” place for that information. But I’m not wedded to that idea, for any reason other than “because it’s what we’ve assumed until now”. And I did think that was the direction @FFY00 was taking sysconfig. But if you (or anyone else) have an alternative suggestion, I’m happy to listen - and in fact, I’d be delighted, because with the best will in the world, the current situation is a bit of a mess. But it would probably need a PEP, and it would have to be a core PEP, not just a packaging one - maybe an “informational” PEP defining an interface which all Python distributors must support, but nevertheless a core Python PEP.

[steve.dower]

We’ll let @FFY00 weigh in, but my position is still that without anything in core/stdlib that needs to know where additional files are installed, they can (and should) be defined independently. Perhaps in terms of values available in sysconfig, but not as part of sysconfig directly.

@pf_moore

And sysconfig does return values for data files and headers for a venv. Admittedly, the header location seems to be in the base install, and I don’t know either why that’s useful or why it’s not the same as venv, but it’s definitely present.

I believe old virtualenv (possibly still current virtualenv) copied the Include directory for CPython into the venv, and likely that code stuck around. But since the includes for CPython are part of CPython, they really can be referenced from the same place even though it’s a virtual environment. (Again, emphasising that these paths are CPython’s paths, not meant for additional packages to use.)

[FFY00 (Filipe Laíns)]

Sorry for the delay folks, I had a couple personal problems, which caused me to be inactive for a bit.

Well, my take on the situation:

• The current status of “sysconfig install schemes” does not meet the requirements of how the packaging tooling evolved over the past few years, and the current design is essentially a left-over from the distutils era
• We should add a new API for install schemes that does not have the limitations that the current one has (being tied to the current keys, only allowing one value per key, etc)
• I don’t have a concrete proposal at the moment for the new install schemes API, but my position is that it should fix the current include/platinclude issue, and it should either address what flags do we need to pass to the compiler, or where to find that information (eg. allowing packages to provide pkg-config files)
• The new API should provide a model that is pretty much a drop-in replacement for the “distutils install schemes” mentioned in the PEP (in the scope of installing files)

@pf_moore

So personally, I’d rather acknowledge that sysconfig acts as the “bare minimum” point of common understanding (and I say “acknowledge” rather than “make” because that’s basically what we’re doing right now, like it or not).

I agree with this. In my opinion, that is one of the main purpose of sysconfig — to be the bridge between core and packaging.

@pf_moore

For my purposes, though, and for the purposes of this thread (or at least this issue raised in the thread), what’s actually needed is a definitive list of what destination directory keys are valid in a wheel, and what directories they should correspond to in the current interpreter environment. And that list needs to be discoverable by applications that have no access to anything but the core interpreter and stdlib, for bootstrapping purposes.

I agree. Something I would like to do is define a list of keys in the Python upstream, and then defer to the PyPA for additional keys. But again, I am not proposing anything just yet.