[Distutils] Add additional file categories for distutils, setuptools, wheel

[Steve Dower]

My brief POV is that if a package on Windows is installing anything outside sys.path at all then it's an application and should use something other than wheel for installation. WiX/MSI will do proper reference counting and upgrades to avoid having multiple versions colliding with each other (imagine installing Mercurial on 2.6 and 2.7 simultaneously...)

These should probably also bundle the interpreter as well to avoid other update issues. I'm already going to release a self extracting zip of the interpreter for this, though there will be tweaks necessary to the initialization process to avoid registry stomping, and tools like pynsist are being worked on to simply installer generation. These can freely install files anywhere, and having a consistent spec for generating these would be nice, but I don't want pip to install files outside of sys.path

Cheers,
Steve

Top-posted from my Windows Phone
________________________________
From: Nick Coghlan<mailto:ncoghlan at gmail.com>
Sent: ‎4/‎19/‎2015 9:41
To: Paul Moore<mailto:p.f.moore at gmail.com>
Cc: DistUtils mailing list<mailto:distutils-sig at python.org>
Subject: Re: [Distutils] Add additional file categories for distutils, setuptools, wheel

On 19 April 2015 at 06:03, Paul Moore <p.f.moore at gmail.com> wrote:
> As a possible compromise, how about an approach where on Linux system
> installs (or more accurately "those install schemes that are relevant
> to the distribution packaging issue you described") the file
> categories are installed into dedicated directories, as described. But
> on other installs (virtualenvs, Windows, maybe OSX) the file
> categories map to locations within package_data, so that they can be
> accessed via normal mechanisms like loader.get_data. Application code
> would need some support code to locate and read the files, but that's
> true whether we go for this proposal or an "outside of site-packages"
> scheme. Also, some things may even be better designated as "don't
> install" in certain schemes (man files, for example, are pretty much
> useless on Windows).

That's not a compromise, that's exactly what I want to see happen :)

If it helps, one way to think of this is as a "file classification"
system, where the packaging tools gain the ability to sort files into
a richer set of categories, and its then up to installers to decide
how those categories map to installation locations. For Windows,
virtualenv, conda, nix, single file applications, etc, that's likely
to be "self-contained application directory". For FHS, it will map to
the on-disk categorisation expected by other tools.

At the moment, because the FHS support is either hacked in, or managed
externally, there's no way for installers to remap the installation
targets for the "self-contained directory" use case.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG at python.org
https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150419/412e084c/attachment.html>