Éric Araujo <merwok <at> netwok.org> writes:
Well, I don’t think they are. The paths used for Windows are a transposition of UNIX paths to C:\\PythonX.Y, with Scripts, Lib, etc. subdirs; they’re not very Windows-y. IOW, I think improving the installation schemes on Windows for 3.3 to feel more native would be a good thing.
See also http://bugs.python.org/issue9878 : Avoid parsing pyconfig.h and Makefile by autogenerating extension module (which means that using C APIs is wholly in line with future direction for sysconfig).
Okay.
Categories are extensible, so it’s a way. See also the short description of the packaging configure command in my other message.
Thinking about it further - I'm not sure it'll be sufficient, in a number of cases, at least under Windows but potentially on other platforms, too. Where software is self-contained, having a fixed set of categories for different types of assets is sensible and sufficient. Where software needs to interoperate with other software, for example, things can get a little more complicated. I've already given an example relating to Powershell. As another example: say I'm developing some software to interoperate with legacy systems such as Microsoft Office (including Outlook) or Sharepoint, which are prevalent in the corporate world. The chances are very high that I'll need to install things in what is, from packaging's perspective, an essentially arbitrary set of locations. It's seems that it's not really possible to codify these using the schemes which we have now - schemes which are perfectly useful in the context of e.g. harmonising how we work with Linux distro packagers. I don't know if this has been brought up before, or discussed and rejected - but I think that something along the lines of Debian's prerm/postrm, preinst/postinst should be available, defined in the same way as setup_hooks in setup.cfg, to be called at the appropriate time in the pysetup3 lifecycle. This would provide some measure of standardisation, allowing projects with simple needs to omit them entirely, but those with more complex needs to do things which we can't foresee. As a bare minimum, prerm and postinst: these can rely on the distribution being installed and so have access to packages inside it. Of course, this is the rationale behind the post-install script option for bdist_wininst. Regards, Vinay Sajip