Re: [Distutils] how to easily consume just the parts of eggs that are good for you
On Wed, April 9, 2008 10:05 pm, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Message: 4 Date: Thu, 10 Apr 2008 12:59:39 +1200 From: Greg Ewing <greg.ewing@canterbury.ac.nz> Subject: Re: [Distutils] how to easily consume just the parts of eggs that are good for you To: distutils-sig@python.org
Paul Moore wrote:
I believe that Mac OS X goes for an even simpler structure - applications store *everything* in the one directory, so that install/uninstall is simply a directory copy/remove.
Yep, and thereby cuts the whole gordian knot, throws the pieces on the fire and burns them. :-)
Package managers have always seemed to me to be an excessively complex solution to a problem that needn't have existed in the first place.
I keep hoping that someday Linux will support something like MacOSX application bundles and frameworks, but I haven't seen any sign of it yet.
I think this discussion arises because the operating systems we are dealing with are based on very different concepts. Windows and Mac are fundamentally single user systems that have added capabilities for multiple users and are intended to be used with proprietary software. Those considerations lead to minimal dependencies among packages (each proprietary provider needs to control its own package, except for the OS), individual users serving as their own sysadmins, and similar factors. Any dependencies in the proprietary software are hidden from the user because the provider has compiled the dependencies into the binary code they supply. Unix/Linux are fundamentally multi-user systems with a distinct role for a sysadmin. Linux and the BSD's are intended to be used with Free/Open Source Software (FOSS), and Unix originated the Software Tools concept in which individual, relatively simple, separately-developed tools are combined to perform complex tasks. Both FOSS and the Software Tools concept encourage dependencies. The need for package managers arises out of the Unix FHS. If you look at the FHS, it is clearly designed to simplify the job of the sysadmin in a multi-user system that uses FOSS and Software Tools. For example, deciding what to backup and how often to do it in a Unix/Linux system is relatively easy for the sysadmin. All the installed software is in certain top-level directories. All the config files are in /etc. All the logs. caches, spools, web pages, process locks, and certain other data are in /var. All the user data is in /home or its sysadmin-determined equivalents. If the sysadmin needs space, deleting files in /tmp will not cause a problem. In summary, Python is being used on systems that have very different underlying OS use cases. To some extent, the natural use case for Python is closest to that of Linux/Unix. Running Python on Windows/Mac requires adapting for those platforms some of the kinds of tools that simplify operations on Linux/Unix systems. This discussion is essentially about how far that goes, how to accomplish it, and how to remain compatible with the existing tools on Linux/Unix. Stan Klein
On 10/04/2008, Stanley A. Klein <sklein@cpcug.org> wrote:
In summary, Python is being used on systems that have very different underlying OS use cases. To some extent, the natural use case for Python is closest to that of Linux/Unix. Running Python on Windows/Mac requires adapting for those platforms some of the kinds of tools that simplify operations on Linux/Unix systems. This discussion is essentially about how far that goes, how to accomplish it, and how to remain compatible with the existing tools on Linux/Unix.
Thanks, that's a good summary. I would dispute your comment that "the natural use case for Python is closest to that of Linux/Unix", however. I think Python is perfectly adaptable to both environments, and from *my* point of view, the issue is that Python is currently well adapted to a Windows environment. It seems that the Unix/Linux users find it less well adapted, and need changes as a result - but in doing so, their changes are disrupting the Windows situation. However, this is from the POV of a Windows developer, who has no sysadmin experience on Windows, and little experience with Unix. So it's certainly biased. But from where I sit, there's no Windows issue to solve, and while I'm happy for the Unix people to address the problems they have, I'd be unhappy if in doing so they *make* problems for Windows. A windows sysadmin may have a different perspective, though. Paul.
On Thu, April 10, 2008 10:47 am, Paul Moore wrote:
On 10/04/2008, Stanley A. Klein <sklein@cpcug.org> wrote:
In summary, Python is being used on systems that have very different underlying OS use cases. To some extent, the natural use case for Python is closest to that of Linux/Unix. Running Python on Windows/Mac requires adapting for those platforms some of the kinds of tools that simplify operations on Linux/Unix systems. This discussion is essentially about how far that goes, how to accomplish it, and how to remain compatible with the existing tools on Linux/Unix.
Thanks, that's a good summary. I would dispute your comment that "the natural use case for Python is closest to that of Linux/Unix", however. I think Python is perfectly adaptable to both environments, and from *my* point of view, the issue is that Python is currently well adapted to a Windows environment. It seems that the Unix/Linux users find it less well adapted, and need changes as a result - but in doing so, their changes are disrupting the Windows situation.
However, this is from the POV of a Windows developer, who has no sysadmin experience on Windows, and little experience with Unix. So it's certainly biased. But from where I sit, there's no Windows issue to solve, and while I'm happy for the Unix people to address the problems they have, I'd be unhappy if in doing so they *make* problems for Windows.
A windows sysadmin may have a different perspective, though.
Paul.
The reason I say that the natural use case for Python is closest to Linux/Unix is that Python is FOSS and its natural approaches encourage dependencies that are not hidden from the user. It is natural in Unix/Linux to install dependencies that are not compiled in as part of a monolithic application and are not bundled with the OS. Although Python is designed to be cross-platform, porting a "FOSS software with dependencies" environment to Windows is outside the natural Windows use case. The natural case in Windows is that all dependencies are either compiled in as part of a monolithic application or are bundled with the OS. One problem is that an excessive focus on tools that solve the "natural use case" issue tends to break the already existing solutions and distribution methods for Unix/Linux. Stan Klein
At 11:36 AM 4/10/2008 -0400, Stanley A. Klein wrote:
The reason I say that the natural use case for Python is closest to Linux/Unix is that Python is FOSS and its natural approaches encourage dependencies that are not hidden from the user. It is natural in Unix/Linux to install dependencies that are not compiled in as part of a monolithic application and are not bundled with the OS.
It's natural for sysadmins... not application developers. Application developers can't rely on system packagers and sysadmins to ship their applications as packages for the OS, *even if* the application *and* the OS are open source. All that's necessary for there to be issues, is that the application and some of its dependencies be in active development. So, all this chatter about what's natural for a given OS is just more provincialism -- i.e., believing that the way things are in one village is The One True Way That Everyone Should Follow. Meanwhile, the real-life use cases exist, and they won't be argued out of existence, any more than the people in other countries cease to exist because they're past the edge of the flat earth. :)
Stanley A. Klein <sklein@cpcug.org> wrote:
Windows and Mac are fundamentally single user systems that have added capabilities for multiple users and are intended to be used with proprietary software. Those considerations lead to minimal dependencies among packages (each proprietary provider needs to control its own package, except for the OS), individual users serving as their own sysadmins, and similar factors. Any dependencies in the proprietary software are hidden from the user because the provider has compiled the dependencies into the binary code they supply.
The problem with this analysis is that the modern Mac is also a capable Unix system, and the "just put everything in a bundle" philosophy that served the Mac so well for so long is beginning to fail. While many Mac apps do still follow this, many more (perhaps the majority) are now Unix apps that have complex inter-package dependencies. Bill
participants (4)
-
Bill Janssen -
Paul Moore -
Phillip J. Eby -
Stanley A. Klein