[Distutils] Install a script to <prefix>/sbin instead of <prefix>/bin

Michael Jansen info at michael-jansen.biz
Sat Dec 7 14:45:32 CET 2013

On Saturday, December 07, 2013 01:16:27 PM Paul Moore wrote:
> I really don't have all the answers here, but...
> On 7 December 2013 12:30, Michael Jansen <info at michael-jansen.biz> wrote:
> > So you consider anything that has parts that need to be installed
> > into/under a web server as not windows compatible?
> Not at all. If you're talking about documents, what's to "install"?
> Just ask the user to drop them under the docroot. If they are
> something like an Apache DLL, just ask the user in the installer where
> Apache is located. Or something like that. There's just no answer that
> assumes everyone's installation is the same and you don't have to get
> information from the user.

If we add something like $wwwroot setup.py could notice this is used and then ask the user where 
to put it. pip/wheel too. Currently it all gets lumped somewhere under data_files and no one has 
any chance to automate this. On linux the default could be to check whatever is appropriate for 
the distribution (/srv/www or /var/www) and if those are not there bail out with the message you 
have to specify the correct path on the command line. That could be the default on windows.

> > Anything that wants to install pdf/html documentation? Manual Pages?
> Why install them. Just put them somewhere for the user to read. Add a
> start menu item if you want them accessible.

For me installing means putting them somewhere for the user to read in an automated, reliable 
and reproducable fashion from sources. So building them (with sphinx or whatever) and copying 
somewhere for the user to read is installing.

> > Anything that needs configuration files which usually end up under /etc
> Well, that's a leading question. There are no such configuration files
> on Windows because there's no /etc. But I know what you mean and the
> answer is put them next to the executable. Or in the registry if you
> believe in that. And generally give the user a configuration app
> rather than expect them to manually edit a file.

But when enhancing distutils with something like $etcdir we could support that easily with minimal 
work for the developer. On linux install into /etc, On windows install wherever it is ok to put those 
stuff (without asking the user) and then provide the script author with an easy way to find out 
where $etcdir is on the platform so he can find his stuff.

Your point of view (i don't want to think about it. Solve it posix only) means people have to 
develop solutions for windows separately and on top of that each and every time manually (and 
most won't do the work) or the other way around. A windows package will not work on linux.

> > Anything that requires a spool file (/var/spool normally)?
> I can't think of anything like that, you'd have to give an example.
> I'm not sure the concept exists on Windows...

Thats just a file where one process pumps data in that another process reads out and handles at 
his leisure.

> Of course, all of the above are *applications*, not Python modules, so
> I wouldn't expect you to distribute them with setuptools/PyPI anyway.
> But that's another aspect of the issue.

Yes it is. And i agree with you that distributing something as cobblerd with pip, pypi is not really a 
good idea. But setuptools is the ONLY build system that works with python code so i HAVE to use it 
to build and install cobblerd from sources. So it should gain support to support applications too. 
Not only libraries and simple scripts.

Anyway. You are at least willing to discuss with me. So thanks. 

I guess i give up on improving setuptools and instead just implement enough to fix cobblerd. 
After that i guess i will take with me the hope that the next time i have contact with python 
packaging the situation improved but i had that hope ten years ago too :( .


Michael Jansen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20131207/e7c7f01f/attachment-0001.html>

More information about the Distutils-SIG mailing list