On 7 December 2013 13:45, Michael Jansen <[email protected]> wrote: > Anyway. You are at least willing to discuss with me. So thanks.
No problem! I hope I wasn't too discouraging - I get the impression that I was :-( My problem is that I don't know the answers on Windows, I only really know enough to know when something feels wrong. In this area, Unix and Windows really are very different, and it shows. Very few people are willing or able to put the effort into developing cross-platform solutions, and those that do are too busy doing it to worry about establishing general principles, etc. > 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 :( . I can understand your situation, but please don't give up! The packaging community definitely needs people willing to help work on these issues. But it's much less about coding solutions, and more about negotiating compromises between people with very different viewpoints. To go back to your original issue (sbin vs bin) - from my point of view as a Windows developer, packages just export commands. Why would I choose to put them in the sbin list rather than the bin list? If that's not clear, then I'll possibly develop packages that don't work "right" on Unix. Let's thrash out the answer to that question first, and *then* worry about implementing it. Is the relevant point that "bin" is on PATH but sbin (typically) isn't? If both are on PATH, I don't see why you bother having two directories. So maybe the real idea here is to split entry points into "commands that should be on PATH" and "commands that should be provided, but not on PATH by default". Or is it? My understanding of sbin on Unix is that it's somehow "system utilities" - but that's just a classification with no practical impact. (What makes formatting a disk a "system utility"? I used to do it all the time when floppy disks were common.) Or maybe sbin is only on PATH when you're root. How does that translate to typical Windows systems, where there is usually only one user, and he has access to everything? Maybe in that context, sbin should be for utilities that require elevation? Lots of questions, but no obvious answers... As I said, and I'll say again, you don't *have* to answer these questions. But not doing so is not "I don't want to think about it, just solve POSIX". Rather it's "let's not make everything wait for a perfect solution when POSIX people need something now". But equally, let's not stop working on the cross-platform solution because the POSIX people have something and no longer care - that's *why* the problem never gets solved properly. One other thing I should say here - you mention your project is "cobblerd". The "d" on the end makes me thing it's a daemon. That's inherently POSIX only - on Windows this would be a service (which is a whole other beast). Actually looking at Cobbler on PyPI it says "Cobbler is a Linux boot server..." so Windows compatibility really isn't crucial in this particular instance, I guess :-) Paul _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
