Re: [Distutils] Platform specific destinations in wheel files?
On Sat, Dec 21, 2013 at 2:57 AM, Nick Coghlan ncogh...@gmail.com wrote: compliant daemon like cobblerd as a wheel file - using Python specific formats to define the layout of full applications, not just libraries. I'd generally been resisting the idea of supporting this (since I favour interoperating with system packaging tools where appropriate over attempting to replace them entirely), but in this case I'm starting to think it may be necessary to support these layouts in the next version of the wheel format in order to *also* support automated conversion of upstream projects to policy compliant system packages. hmm I tend to think, like you, that this isn't a problem wheel should solve, but can also see the advantages...for the moment though talking about how it would solve it may help clarify whether it should. adding a new name.app subdirectory in parallel. A wheel that had content in app would be inherently platform specific - you wouldn't be permitted to use the new directory in a cross-platform wheel file. The defined subdirectories of app would also be platform specific. is this necessary -- couldn't there be a way to provide the info in a cross-platform way, and have it mapped to the platform specific locations at install-time? All POSIX systems would at least support the fhs subdirectory. For a system install, this would map to /, for a virtualenv install it would map to the root of the virtualenv and for a user install it would map to ~/.local. then you explicitly put in bin, sbin, share, whatever? This seems really klunky to me, and also forces platform dependence, and is fundamentally tied to how posix does things Maybe it's not possible, but I suggest that we could pre-define the locations that might be needed: executables (bin) system_executables (sbin) user_executables (./bin) documentation (doc) system_data_files (share ?) user_data_files (./share ) app_configuration (/etc/appname) user_app_configuration (./.app_name : ./Library ) This could end up being a pretty big list, but I think it could be finite. Then at install-time, the installer maps these to the appropriate place on the system. It's a little different application, but wxWidgets does this pretty successfully with wxStandardPaths. -Chris I'm not sure what other subdirectories would be appropriate for Windows or Mac OS X, although I expect being able to install into Program Files and Application Data would be interesting for Windows apps, and into an application folder for Mac OS X. It's really the potential for FHS support that drives my interest in the idea, but if we're going to do something like this at all, it shouldn't be POSIX specific. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Platform specific destinations in wheel files?
On 23 December 2013 20:53, Chris Barker chris.bar...@noaa.gov wrote: then you explicitly put in bin, sbin, share, whatever? This seems really klunky to me, and also forces platform dependence, and is fundamentally tied to how posix does things Maybe it's not possible, but I suggest that we could pre-define the locations that might be needed: Agreed. My biggest concern with this whole idea is that developers (typically POSIX developers, but it applies equally to all) will *think* they need something like sbin because they are used to the concept from their environment, and so write their wheel to use it and hence be platform specific. However, with a little thought (possibly hardly any thought in the case of sbin :-)) they could have chosen a more generic approach which makes their project available to users of other platforms. This has been a very common issue historically, and I'm very reluctant to add anything that makes it easier to limit usability of packages across platforms. Portable by default should be the principle. But I see there is a need, and I understand that practicality beats purity. Let's just make sure that it's more effort to use the platform-specific approach than not to, so it doesn't become an attractive nuisance. BTW, I like your idea of defining generic locations - but in the past efforts to do this have been doomed to death by bikeshedding and platform wars. So while I agree in principle, I fear it may not happen in practice :-( Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Platform specific destinations in wheel files?
On Mon, Dec 23, 2013 at 4:22 PM, Paul Moore p.f.mo...@gmail.com wrote: On 23 December 2013 20:53, Chris Barker chris.bar...@noaa.gov wrote: then you explicitly put in bin, sbin, share, whatever? This seems really klunky to me, and also forces platform dependence, and is fundamentally tied to how posix does things Maybe it's not possible, but I suggest that we could pre-define the locations that might be needed: Agreed. My biggest concern with this whole idea is that developers (typically POSIX developers, but it applies equally to all) will *think* they need something like sbin because they are used to the concept from their environment, and so write their wheel to use it and hence be platform specific. However, with a little thought (possibly hardly any thought in the case of sbin :-)) they could have chosen a more generic approach which makes their project available to users of other platforms. This has been a very common issue historically, and I'm very reluctant to add anything that makes it easier to limit usability of packages across platforms. Portable by default should be the principle. But I see there is a need, and I understand that practicality beats purity. Let's just make sure that it's more effort to use the platform-specific approach than not to, so it doesn't become an attractive nuisance. Attractive nuisance is the first phrase that comes to mind when I think of the FHS. BTW, I like your idea of defining generic locations - but in the past efforts to do this have been doomed to death by bikeshedding and platform wars. So while I agree in principle, I fear it may not happen in practice :-( Paul The GNU autoconf paths are the obvious choice. It would be really easy to try adding these to the dict that wheel installers use to relocate stuff. http://www.gnu.org/prep/standards/html_node/Directory-Variables.html ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
