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:[email protected]> Sent: 4/19/2015 9:41 To: Paul Moore<mailto:[email protected]> Cc: DistUtils mailing list<mailto:[email protected]> Subject: Re: [Distutils] Add additional file categories for distutils, setuptools, wheel On 19 April 2015 at 06:03, Paul Moore <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
