At 10:00 AM 4/9/2008 +0200, Gael Varoquaux wrote:

On Wed, Apr 09, 2008 at 12:41:32AM -0400, Phillip J. Eby wrote:

...

...

The way to achieve a database for Python would be to provide tools for conversion of eggs to rpms and debs,

...

Such tools already exist, although the conversion takes place from source distributions rather than egg distributions.

What is the status of the deb backend? The only one I know is unofficial maintained by Andrew Straw, but my information my be lagging behind.

I was under the impression that there were 2 .deb tools, neither one "official" in any sense, any more than 'bdist_rpm' is really "official" for RPM-based systems.

By the way, if these tools work well, they are priceless!

I haven't had need to use any of them, so I don't really know.

All my development is done on Linux. I use Windows very minimally (such as for tax preparation) and unless forced to do so for specific circumstances (such as submittal to grants.gov) do not expose Windows to the Internet. In the future there may possibly arise a need for us to port some Linux-developed Python code to Windows, but we will have to cross that bridge when we get there. I think you raise an interesting issue: What is a package manager? I have minimal experience installing packages on Windows over the last 5-10 years, but in my experience a Windows package comes as an executable that, when run, installs itself. Unless a third-party program monitors the installation, uninstalling is a nasty chore, as is finding out what files were installed or where they went. The rpm and deb package managers (and their yum and other higher level dependency managers) do a lot of things: 1. They install packages and maintain databases of what packages were installed 2. They manage dependencies 3. They support clean uninstalling of packages 4. They can query packages, both installed (via their databases) and not yet installed (e.g., as rpm or deb files), to determine attributes, such as files they install, dependencies, and other information defined at packaging time. 5. They build packages and (in some cases) can rebuild packages. 6. They can verify packages for integrity and security purposes. 7. They can download package files and maintain archives of installed package files for use as local repositories. There may be other functions, but the above is a top-of-the-head list. I can say that I'm not terribly happy with Python packaging that is only minimally compatible with rpm. I haven't used Ubuntu all that much. I do like Ubuntu's packaging and package management, and I do know that there are programs, such as alias, that can translate from rpm to deb formats. I don't think I ever said that Windows is broken in the area of package management. My own experience is that the files of Windows programs tend to be put in a directory devoted to the program, rather than put in directories with other files having similar purposes. At one time, the default location in Windows for word processing files was even in a sub-directory of the word processing program. That changed to having a form of user home directory, but it didn't change much for the program files themselves. Unix/Linux puts the files in specific areas of the file system having functional commonality. One could almost say that the Windows default approach to structuring its filesystem avoids or minimizes the need for package management. I repeat that this issue mainly arises because Windows doesn't have the same kind of filesystem structure (and therefore the need for package management) that other systems have. I don't know what Windows add/remove programs function does, but all it might do is to run the executable to install packages and record the installation (as was previously done by third party programs) to facilitate clean removal. Unless you can perform more of the other functions I listed above, I doubt I would call add/remove a package manager. Stan Klein On Wed, April 9, 2008 1:23 pm, Paul Moore wrote:

On 09/04/2008, Stanley A. Klein wrote:

...

IMHO, the main system without a package manager is Windows. A reasonable way to deal with Windows would be to create a package manager for it that could be used by Python and anyone else who wanted to use it. The package manager could establish a file hierarchy similar to the Unix FHS and install files appropriately, except for what is needed to satisfy the Windows OS. That would probably go a long way to addressing the issues being discussed here. This is primarily a Windows problem, not a Python problem.

Windows does have a package manager - the add/remove programs application. It's extremely limited, and doesn't make any attempt at doing dependency resolution, certainly - but that's a separate issue.

I don't know if you use Windows (as in, develop programs using Python on Windows). If you do, then I'd be interested in your views on bdist_wininst and bdist_msi installers, and how they fit into the setuptools/egg environment, particularly with regard to the package manager you are proposing. If you don't use Windows, then I don't see how you can usefully comment.

Personally, as I've said before, I don't have a problem with a Python-only package manager, as long as it replaces or integrates bdist_wininst and bdist_msi. Having two package managers is far worse than having none - and claiming that add/remove programs "isn't a package manager" is just ignoring reality (if it isn't, then why do bdist_wininst and bdist_msi exist?).

Are the Linux users happy with having a Python package manager that ignores RPM/apt? Why should Windows users be any happier?

Sorry - I'm feeling a little grumpy. I've read one too many "Windows is so broken that people who use it obviously don't care about doing things right" postings this week :-(

Paul.

--

On Wed, April 9, 2008 3:19 pm, Gael Varoquaux wrote:

On Wed, Apr 09, 2008 at 02:26:31PM -0400, Stanley A. Klein wrote:

...

The rpm and deb package managers (and their yum and other higher level dependency managers) do a lot of things:

...

1. They install packages and maintain databases of what packages were installed 2. They manage dependencies 3. They support clean uninstalling of packages 4. They can query packages, both installed (via their databases) and not yet installed (e.g., as rpm or deb files), to determine attributes, such as files they install, dependencies, and other information defined at packaging time. 5. They build packages and (in some cases) can rebuild packages. 6. They can verify packages for integrity and security purposes. 7. They can download package files and maintain archives of installed package files for use as local repositories.

You are collapsing three different functionalities in one:

* Dealing with repositories and downloading: yum/apt

* Installing + uninstalling packages, and dealing with system consistency (thus checking the dependencies are available): rpm/dpkg

* Building

For me it is important that the 3 are separated:

* I may want to download the dependencies of a package to burn to a CD for a computer that does not have internet access.

* I may want to send a tarball to a build server that does the building, but no install (so as not to corrupt my working system).

Cheers,

Gaël

Gael - The functionalities are combined in programs but are not necessarily required to be used all at the same time. I'm not that familiar with apt, but yum also installs, including downloading both a package and its dependencies. Yum also has a query capability (yum list, yum info). I think synaptic does the same thing yum does, and adds a GUI and search capabilities similar to yum info as well. The build capabilities of rpm were moved to rpmbuild, but the building remains part of the rpm system. IIRC, bdist_rpm actually calls rpmbuild as part of its processing. Also, IIRC, rpmbuild can build from a tarball if it contains an rpm spec. It does not install in the same process. That is a separate step. You would not corrupt your working system by building an rpm from a tarball on it. BTW, I would not want to do dependencies with rpm if yum is available. Doing dependencies with rpm is very difficult and it is easy to wind up in "dependency hell". Yum will find the dependencies and install them as long as they are in repositories that are registered in the yum configuration. I looked at "man yum" and couldn't find an option to download dependencies to the local repository without installing. However, if you did install a package and its dependencies, and if you have selected the option of retaining the cache and not cleaning it after installation, the rpms (e.g., for updates) are in /var/cache/yum/updates/packages/. They can be copied from there to a CD for a system without internet connectivity. Also, both Fedora and Ubuntu have software for building installable live CD's, although I don't know how they get their package files. Stan Klein

On 09/04/2008, Stanley A. Klein wrote:

I think you raise an interesting issue: What is a package manager?

My (very simplistic) answer is that it's whatever someone uses to manage packages. What level of functionality it has is irrelevant, as long as it suits an individual's way of working.

I don't think I ever said that Windows is broken in the area of package management.

I hope I didn't say you had - but it is an often-raised point, and it does grate on me (as by implication, it says that what I do isn't "real" package management). It's just another flavour of the old Windows vs Linux OS wars, which I don't want to participate in :-)

My own experience is that the files of Windows programs tend to be put in a directory devoted to the program, rather than put in directories with other files having similar purposes. At one time, the default location in Windows for word processing files was even in a sub-directory of the word processing program. That changed to having a form of user home directory, but it didn't change much for the program files themselves. Unix/Linux puts the files in specific areas of the file system having functional commonality. One could almost say that the Windows default approach to structuring its filesystem avoids or minimizes the need for package management.

Agreed. The minimal package manager on Windows is arguably reasonable precisely because the standard layout doesn't require much more. On the other hand, Microsoft has a bad habit of changing their "standards", and in particular Vista changes a lot of things. But that's very off-topic, so I'll avoid going into detail here.

I repeat that this issue mainly arises because Windows doesn't have the same kind of filesystem structure (and therefore the need for package management) that other systems have. I don't know what Windows add/remove programs function does, but all it might do is to run the executable to install packages and record the installation (as was previously done by third party programs) to facilitate clean removal.

Precisely. I could argue that the Linix filesystem structure is over complex, and causes the need for complex package managers, precisely because it's impossible to manually keep track of what file is owned by what package. But this way lies OS wars, so I won't make a major point of this, but just ask that people consider it as a possibility. (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. I won't comment on what that proves...)

Unless you can perform more of the other functions I listed above, I doubt I would call add/remove a package manager.

OK. I would, though, as I don't really want much more. Later, you said:

I just don't do Windows. :-)

And you've been pretty clear that you're looking for information rather than trying to explain how you think Windows should work. But many people aren't so balanced in their views, and that makes it hard to have a discussion - I'd suggest that people without Windows experience leave the Windows side to the Windows people, and accept that when they say "XXX won't work for us", that the statement is probably true. I find this whole discussion hugely confusing, because a lot of people are stating opinions about environments which it seems they don't use, or know much about. I don't know how to avoid this, but it does make it highly unlikely that any practical progress will get made. Paul.

At 12:51 AM 4/10/2008 +0200, Gael Varoquaux wrote:

On Wed, Apr 09, 2008 at 11:46:19PM +0100, Paul Moore wrote:

...

I find this whole discussion hugely confusing, because a lot of people are stating opinions about environments which it seems they don't use, or know much about. I don't know how to avoid this, but it does make it highly unlikely that any practical progress will get made.

I find that something that doesn't help at all the discussion move forward is that everybody has different usecases in mind, on different platforms, and is not interested in other people's usecases.

Hopefuly I am wrong,

You're not wrong at all. I have to deal with *all* the platforms and use cases, which makes it quite frustrating when people who haven't even read the requirements are making proposals to "solve" things in ways that break for everyone except their own niche platform+usecase combination. Guido, can I borrow the time machine and go back and NOT try to improve on the distutils? Or is there already too much collateral damage to the timeline? ;-)

On Thu, 10 Apr 2008, Greg Ewing wrote:

Paul Moore wrote: [...] 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.

Not the same, but "something like": http://0install.net/ John

On Sat, 12 Apr 2008, Greg Ewing wrote:

John J Lee wrote:

...

...

I keep hoping that someday Linux will support something like MacOSX application bundles and frameworks,

Not the same, but "something like":

http://0install.net/

That looks interesting, but I'm not sure I'd quite call it "something like". It looks like another case of adding more complexity to fight existing complexity, rather than removing the original complexity.

In other words, it seems to be just another package manager, albeit a particulary nice-sounding one.

It allows you to think about "uninstallation" as "delete the app == delete the file" ("the file" might be different in different systems -- e.g. with ROX, it seems very similar to how I imagine Mac OS applications look, and certainly very similar to how RISC OS apps used to look). But it also (plausibly) claims to allow sharing of the data that comprises an application and its dependencies between users who don't trust each other (while preserving other desirable properties like the one in the previous paragraph, such as avoidance of version conflicts, etc.). I think that property probably justifies the added implementation complexity over unshared directories of files. And the desire for that property isn't a consequence of fighting existing complexity, right? John

On Sun, 13 Apr 2008, Greg Ewing wrote:

John J Lee wrote:

...

It allows you to think about "uninstallation" as "delete the app == delete the file"

But 0install doesn't do that, as far as I can tell -- it still keeps the data in some mysterious form and location known only to itself, and requires you to use special tools to install/remove apps.

If you have a network connection, about the only reason for not wanting an app to be "installed" is that it has changed the behaviour of your system somehow, just by being in the "installed" state. But the presence of an app in the 0install cache -- which is what you mean here by "installed" -- doesn't change the behaviour of your system. One other reason, of course, is to free up disk space. You're correct that special tools are needed to manage the cache, and that that complicates the UI. I think that's a fair price to pay for safe sharing of data between users.

...

with ROX, it seems very similar to how I imagine Mac OS applications look

Yes, ROX is very MacOSX-like, but I don't think it has anything to do with 0install.

0install provides one way of implementing that kind of system. If you want to share data, it's a better way than unshared directories of files. That's how 0install and ROX are related, from this perspective.

...

But it also (plausibly) claims to allow sharing of the data that comprises an application and its dependencies between users who don't trust each other

If ROX apps included a checksum, and the system verified it before running the app, that would give you the same thing trust-wise, I think. [...]

That's an interesting idea, but how would the system find the app? If it doesn't, the data won't be shared. John

On Mon, 14 Apr 2008, Greg Ewing wrote:

John J Lee wrote:

...

If you have a network connection, about the only reason for not wanting an app to be "installed" is that it has changed the behaviour of your system somehow, just by being in the "installed" state.

If you have a continuous high-speed network connection and aren't concerned about cost or bandwidth use or disk space taken up, it might make sense to have apps downloaded on demand,

http://0install.net/faq.html#id2324452 Practically, I suspect the sharing and caching will result in lower network bandwidth usage. I guess practically, that's a matter to be answered mostly by measurement in common usage patterns, rather than by argument.

cached, etc. But not everyone works that way. I don't, much of the time. I prefer it when downloading an app and putting it on my system is an explicit step.

You'll be the first against the wall when the revolution comes ;-)

...

...

Yes, ROX is very MacOSX-like, but I don't think it has anything to do with 0install.

0install provides one way of implementing that kind of system.

But it doesn't, if by "that kind of system" you mean one where an app or library is just an ordinary filesystem object. A 0install app appears to be very far from ordinary.

Of course, I understand exactly what you mean. But since the answer to those kinds of questions depends on our different ideas of how "an app" or "installed" can most usefully be defined, I guess debating the words here is less profitable than the concepts and their consequences. I genuinely do suspect that the 0install model is simpler to understand than the "unshared directories of files" model (I won't really be confident unless and until I actually use the thing a lot, of course). [...]

...

...

If ROX apps included a checksum, and the system verified it before running the app, that would give you the same thing trust-wise, I think.

That's an interesting idea, but how would the system find the app?

The system doesn't have to find the app -- the user finds the app, using the same techniques he uses to find anything else in the filesystem he's interested in.

In somebody else's user account, right? And the dependencies? And what app is that, anyway? http://0install.net/survey.html """If you don't know the hash, you can't trust it! Making it easy to browse the cache "Hey look - there's the Gimp! Let's run it!" is therefore an anti-goal.""" Of course, you could specify both the app (== URL, or hash, or pet name for it, or something like that) *and* where its data is on the disk, but that's a more complicated and less useful interface. John

David Cournapeau wrote:

There are two ways of looking at it, I think. One is to think that linux FHS (and unix in general) is totally broken.

I don't think it's *totally* broken. I do think it goes overboard with splitting things up and scattering them around. I understand that there are reasons for some of that, but I don't see why e.g. includes, library files and other resources used by a package can't be kept together.

I personally really like how gobo linux tries to go around that:

http://www.gobolinux.org/

Hadn't heard of that before -- it sounds quite nice! Rather like MacOSX might look if it had dependency management. -- Greg

At 11:52 AM 4/9/2008 -0400, Stanley A. Klein wrote:

However, are you implying that the installation information for Python egg packages accesses and coordinates with the rpm database?

Yes, when the information isn't stripped out. Try a more recent Fedora.

IMHO, the main system without a package manager is Windows.

You're ignoring shared environments and development environments. (Not to mention Mac OS.)

A reasonable way to deal with Windows would be to create a package manager for it that could be used by Python and anyone else who wanted to use it.

Let us know when you've finished it, along with the one for Mac OS. :) Of course this still won't do anything for shared environments and development environments.

You are talking here about bdist_rpm and not about a tool that would take a Python package distributed as an egg file and convert the egg to an rpm or a deb. Unfortunately, some Python packagers are beginning to limit their focus only to egg distribution. That creates a problem for users who have native operating system package management.

That is indeed a problem -- but it's a social one, not a technical one. It's trivial for the publisher of an egg to change their command line from "setup.py bdist_egg upload" to "setup.py sdist bdist_egg upload", as soon as their users (politely) request that they do so.

...

Applying LSB and FHS to the innards of Python packages makes as much sense as applying them to the contents of Java .jar files -- i.e., none. If it's unchanging data that's part of a program or library, then it's a program or library, just like static data declared in a C program or library. Whether the file extension is .py, .so, or even .png is irrelevant.

The FHS defines places to put specific kinds of files, such as command scripts (/bin, /usr/bin, /sbin, or /usr/sbin), documentation (/usr/share/doc/package-name), and configuration files (/etc). There are several kinds of files identified and places defined to put them. Distribution by eggs has a tendency to scoop up all of those files and put them in /usr/lib/python/site-packages, regardless of where they belong.

Eggs don't include documentation or configuration files, and they install scripts in script directories, so I don't get what you're talking about here. For any other data that a package accesses at runtime, my earlier comments apply.

Having eggs support conformance to FHS would mean recognizing and tagging the relevant files. A tool for converting eggs to rpms or debs would essentially reformat the egg to rpm or deb and put files where they belong.

No, because such files as you describe don't exist. If you think they do, then either you have misunderstood the nature of the files in question, or the developer has incorrectly placed non-runtime files in their installation tree.

At 04:43 PM 4/9/2008 -0400, Stanley A. Klein wrote:

I don't understand what you mean by "shared environments and development environments".

I mean that in a shared or development environment, a system packager isn't useful, since it expects things to live in *one* place, and usually to have only one *version*, as well.

I agree that we are dealing with a combination of technical and social issues here. However, I think it takes a lot more understanding for a publisher to get everything straight.

If they provide you with the source distribution, you can make any sort of package you want.

...

Eggs don't include documentation or configuration files, and they install scripts in script directories, so I don't get what you're talking about here. For any other data that a package accesses at runtime, my earlier comments apply.

But rpms and debs do include these files, plus manual pages, localization files and a lot of other ancillary stuff.

...just one of the many reasons that eggs are not a replacement for rpms and debs. :)

Most of the Python tarballs I have downloaded have all kinds of files in their installation trees. This is a major pain in the you-know-what for someone trying to use bdist_rpm and get proper, FHS-compliant rpms. If eggs are supposed to be strictly runtime files, I think very few developers actually understand that. Better yet, how do you define what should be included in an installation? It sounds like the egg concept doesn't include several kinds of files that rpm and deb would include in an installation. I think that may be an important issue here.

It would be, if .eggs were a packaging format, rather than a binary distribution/runtime format. Remember "eggs are to Python as jars are to Java" -- a Java .jar doesn't contain documentation either, unless it's needed at runtime. Same for configuration files. They're not system packages, in other words. The assumption that they are is another marketing failure, due to conflation of "package == distribution of python code" and "package == thing you manage with a system packager". People see, "I put my package in an .egg" and think it's the latter definition, when it's barely even the former. :)

Phillip J. Eby wrote:

It would be, if .eggs were a packaging format, rather than a binary distribution/runtime format.

Remember "eggs are to Python as jars are to Java" -- a Java .jar doesn't contain documentation either, unless it's needed at runtime. Same for configuration files.

But there's generally no need to easily have a look into a .class file with a tool the user is used to whereas for python, we're often interested in knowing the details. And having a zip file in my way to the source has left me frustrated often enough. If you want to be consequent and consistent leave out the .py files from eggs, a jar file normally doesn't contain .java sources files either.

They're not system packages, in other words. The assumption that they are is another marketing failure, due to conflation of "package == distribution of python code" and "package == thing you manage with a system packager". People see, "I put my package in an .egg" and think it's the latter definition, when it's barely even the former. :)

I agree that they are not system packages, but I would have prefered to install multiple versions of a package to separate "site-packages" directories, something that is really well understood by most unsofisticated python programmers. The selection of the version could then be made at runtime by a PYTHONPATH setting and not by fiddling with .pth files (something that could be autmated by a tool and persisted in batch files).

At 03:20 PM 4/9/2008 -0700, zooko wrote:

I've opened a ticket on my setuptools trac about this proposal:

http://allmydata.org/trac/setuptools/ticket/5 # binary eggs should come with .py files by default, rather than .pyc files

Filling your tracker with already-rejected proposals isn't likely to encourage me to look at it, especially when I've personally rejected them to you in IRC. That goes for your ticket #4 as well.

Phillip J. Eby wrote:

...

...

Applying LSB and FHS to the innards of Python packages makes as much sense as applying them to the contents of Java .jar files -- i.e., none. If it's unchanging data that's part of a program or library, then it's a program or library, just like static data declared in a C program or library. Whether the file extension is .py, .so, or even .png is irrelevant.

The FHS defines places to put specific kinds of files, such as command scripts (/bin, /usr/bin, /sbin, or /usr/sbin), documentation (/usr/share/doc/package-name), and configuration files (/etc). There are several kinds of files identified and places defined to put them. Distribution by eggs has a tendency to scoop up all of those files and put them in /usr/lib/python/site-packages, regardless of where they belong.

Eggs don't include documentation or configuration files, and they install scripts in script directories, so I don't get what you're talking about here. For any other data that a package accesses at runtime, my earlier comments apply.

We've talked a bit about this before, and IIRC, at that time you (Phillip) were willing to consider patches to setuptools that allowed for the inclusion of documentation in eggs such that it was placed into an LSB/FHS appropriate directory (or some standard dir for non-LSB systems) during the install process. I'm assuming that something similar for config files wouldn't be a problem either? Or is this whole idea out the window given the way the discussion has trended and the reiteration above that eggs are meant to be similar in principal to jars? Not that I have a patch yet, but we've been working on it in our "spare time" over here at Enthought. I'm now wondering if we're wasting our time. :-) I think the biggest use-case confusion in the current discussion is whether we're talking about applications or libraries? If we're talking about libraries, then clearly distribution of only executables is sufficient because anything else should be handled by the application distribution when that library is used in an app. Whereas if we're talking about applications, you probably *do* want to include documentation, configuration info, etc. in your distribution. I think I can sum up any further points by simply asking: "Should it be safe to assume I can distribute my application via eggs / easy_install just because it is written in Python?" -- Dave

Stanley A. Klein wrote:

On Wed, 2008-04-09 at 18:17 -0500, Dave Peterson wrote:

...

I think I can sum up any further points by simply asking: "Should it be safe to assume I can distribute my application via eggs / easy_install just because it is written in Python?"

I think that based on this discussion the bottom line answer to this question is "No".

I agree that it seems like that's where things are headed in the discussion. But the discussion doesn't always coincide with the reality, right? I guess I'm trolling more for a statement from the setuptools maintainer here. Particularly since I'm looking for an answer to my question about should Enthought continue to invest time into a setuptools patch that lets developers include docs, config files, etc. in eggs for installation in a FHS-approved location at install time? -- Dave

Phillip J. Eby wrote:

At 03:48 PM 4/10/2008 -0500, Dave Peterson wrote:

...

Stanley A. Klein wrote:

...

On Wed, 2008-04-09 at 18:17 -0500, Dave Peterson wrote:

...

I think I can sum up any further points by simply asking: "Should it be safe to assume I can distribute my application via eggs / easy_install just because it is written in Python?"

I think that based on this discussion the bottom line answer to this question is "No".

I agree that it seems like that's where things are headed in the discussion. But the discussion doesn't always coincide with the reality, right? I guess I'm trolling more for a statement from the setuptools maintainer here.

Particularly since I'm looking for an answer to my question about should Enthought continue to invest time into a setuptools patch that lets developers include docs, config files, etc. in eggs for installation in a FHS-approved location at install time?

I think it's more than reasonable to define a standard for including such data. I'm somewhat more skeptical about doing that installation automatically within easy_install. Likewise, I'm skeptical about doing other sorts of non-package, non-script installation. I'd like to see proposals that show due care to cross-platformness, uninstallability, etc.

In other words, when it comes to a "patch" -- the documentation is going to count for a lot more than the code, and I'd rather see a concrete proposal well in advance of the patch.

Sooner would be better than later, too, because it's likely that the plan for "non-egg installs" is going to be affected by the plan as well.

I believe I understand, and agree, with your concerns. Let me be clear on the status of where we are in our work: we've internally talked through a number of design possibilities, and are now trying out (via hacking on setuptools) how the one we thought was "best" worked out. In particular, we're concerned about the difficulty of use in terms of even just the use-cases we have for ETS projects. Also, since we do a bit of cross-platform deployment, we're also investigating those effects on the design as well. That being said, I don't think we're ready to put forward a proposal that would withstand too much public scrutiny quite yet - at least if the resulting discussion implied a significant time or effort commitment on our part to carry the conversation forward. If it sounded like we'd already figured it all out, I apologize for getting people's hopes up! I just wanted to make sure further pursuit in this direction on our part wasn't completely wasted. The above not withstanding, if anyone is interested in talking about it / helping us, we certainly wouldn't ignore you. I just can't promise immediate responses due to pretty pressing customer commitments on our part. Regarding the mention of 'uninstallability' above, I assume it would be sufficient if the installed files were simply included in the generated list of files provided by the "--record" option since there is currently no uninstall command at all? Or is there something else you'd like to see as an intermediate measure? I'd love to add an uninstall option to easy_install as well (it's something we get hit about alot by our user community) but there's only so many hours in a day. ;-) -- Dave

"Stanley A. Klein" writes:

IMHO, the main system without a package manager is Windows.

AFAICT the MacOS platform also lacks in this area.

A reasonable way to deal with Windows would be to create a package manager for it that could be used by Python and anyone else who wanted to use it. [...] This is primarily a Windows problem, not a Python problem.

I'd rephrase this as: If you *must* re-invent package management for those legacy systems without it, please *don't* make it specific to Python. -- \ “The right to search for truth implies also a duty; one must | `\ not conceal any part of what one has recognized to be true.” | _o__) —Albert Einstein | Ben Finney

On Wed, Apr 09, 2008 at 11:52:08PM +0100, Paul Moore wrote:

And I would say that Windows doesn't have a problem. Are any Windows users proposing building a package management system for Windows (Python-specific or otherwise)? It's a genuine question - is this something that Windows users are after, or is it just Linux users trying to show Windows users what they are missing?

Well, users don't phrase this that way, because they don't know what package management (or rather automatic dependency tracking) is, but yes, they are some usecases. It is nowadays really tedious to deploy Python applications making uses of many packages on Python. The scientific community is a domain in which this problem is crucial, as we are trying to ship desktop applications to non-computer-savy people, with many dependencies outside the standard library. Enthought is working on shipping a Python distribution with some sort of package management for this purpose ( see http://code.enthought.com/enstaller/ ), and finding it is not an easy problem. Cheers, Gael

Paul Moore wrote:

And I would say that Windows doesn't have a problem. Are any Windows users proposing building a package management system for Windows (Python-specific or otherwise)? It's a genuine question - is this something that Windows users are after, or is it just Linux users trying to show Windows users what they are missing?

I think the requirements for a package manager are different on different platforms. On Linux, you need to be able to cope with files scattered all over the system, and complex webs of dependencies between packages. On Windows, you need to be able to cope with scattered files and multiple applications sharing a file, but not usually with dependencies, because each application typically comes with all the files it needs (even if some of them might not get installed because they're already there for another application). On MacOSX, applications are usually completely self-contained, include all their dependencies and are not spread around, so there's really nothing for a package manager to do. What all this means for Python package management, I really don't know. Whatever is done, I'd like to see it kept as dirt-simple as possible. Ideal would be the MacOSX situation where the package is just a directory of files that you put somewhere obvious, and you can tell what it is just by looking at it, and get rid of it by dragging it to the trash -- so you don't need a package manager. -- Greg