Re: [Distutils] how to easily consume just the parts of eggs that are good for you
Stanley A. Klein skl...@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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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, 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. I know you can use 0install that way, but I do it already on my MacOSX system without needing any special tool. :-) 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. If you want to share data, it's a better way than unshared directories of files. There's nothing to stop a MacOSX user from putting an app in a publically-readable place and letting other people use it. I don't see what the big deal is there. 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. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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. 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. 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. Dependency management is the part I agree is lacking in a MacOSX-like approach. Some tool for helping with that would be good to have. But I don't think it's necessary to make the components whose dependencies are being managed into anything complicated or mysterious in order to get that. They should just be files or directories that I can put into place myself, and look at to find out what I have. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 [EMAIL PROTECTED] wrote: Message: 4 Date: Thu, 10 Apr 2008 12:59:39 +1200 From: Greg Ewing [EMAIL PROTECTED] 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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
On Thu, April 10, 2008 10:47 am, Paul Moore wrote: On 10/04/2008, Stanley A. Klein [EMAIL PROTECTED] 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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
On Wed, Apr 09, 2008 at 11:37:07AM +1000, Ben Finney wrote: zooko [EMAIL PROTECTED] writes: I am skeptical that prorgammers are going to be willing to use a new database format. They already have a database -- their filesystem -- and they already have the tools to control it -- mv, rm, and PYTHONPATH. Many of them already hate the existence the easy_instlal.pth database file, and I don't see why a new database file would be any different. Moreover, many of us already have a database of *all* packages on the system, not just Python-language ones: the package database of our operating system. Adding another, parallel, database which needs separate maintenance, and only applies to Python packages, is not a step forward in such a situation. 90 % (at least) of the world does not have such database. I, and probably you, have such a very nice database. I works well, and we can choose to forget the problems our users are facing. It does not solve them though. In addition, packaging is system-specific. I recently had to learn some Debian packaging, because I wanted my Ubuntu and Debian users to be able to use my projects seamlessly. What about RPMs for RHEL, Fedora, Mandriva? ... and coronary packages? and MSIs? ... When do I find time to do development if I have to learn all this packaging. It would be fantastic to have an abstraction on all these packaging systems, including, as you point out, their database. I do agree that reusing the system packaging's database is great, and would be the best option for system-wide install. However one of the very neat features of setuptools and eggs is that you don't need administrator access to install the packages, and that is great in a shared environment, like a computation cluster. The system's database is thus unfortunately not a complete solution to the problem. My 2 cents, Gaël ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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. By the way, if these tools work well, they are priceless! Cheers, Gaël ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
On Wed, April 9, 2008 12:41 am, Phillip J. Eby wrote: At 10:49 PM 4/8/2008 -0400, Stanley A. Klein wrote: On Tue, April 8, 2008 9:37 pm, Ben Finney [EMAIL PROTECTED] wrote: Date: Wed, 09 Apr 2008 11:37:07 +1000 From: Ben Finney [EMAIL PROTECTED] Subject: Re: [Distutils] how to easily consume just the parts of eggs thatare good for you To: Distutils-Sig@Python.Org zooko [EMAIL PROTECTED] writes: eyes and said So they are planning to reinvent apt!. That's pretty much my reaction, too. I have the same reaction. I'm curious. Have any of you actually read PEP 262 in any detail? I have seen precious little discussion so far that doesn't appear to be based on significant misunderstandings of either the purpose of reviving the PEP, or the mechanics of its proposed implementation. I haven't read the PEP at all. I generally don't read PEP's. I have tried in the past to use easy_install, but have run into problems because there is no communication between easy_install and the rpm database, resulting in failure of easy_install to recognize that dependencies have already been installed using rpms. This problem doesn't exist with Python 2.5, unless you're using a platform that willfully strips out the installation information that Python 2.5 provides for these packages. IIRC, I have had the problem with Python 2.5 on Fedora 7. Until recently, Fedora packagers did strip out the egg information included with Python packages they packaged. I left those files in when packaging myself using bdist_rpm. However, are you implying that the installation information for Python egg packages accesses and coordinates with the rpm database? I found myself having to go into the setup.py for the relevant package(s) and delete any statements regarding dependencies. Otherwise, IIRC, the packaging couldn't proceed because the Python packaging tool couldn't find the dependencies that had already been installed as rpms. After installation, Python managed to find the relevant files, but the packaging tool couldn't. A database focused only on Python packages is highly inappropriate for Linux systems, violates the Linux standards, and creates problems because eggs are not coordinated with the operating system package manager. The revamp of PEP 262 is aimed at removing .egg files and directories from the process, by allowing system packagers to tell Python what files belong to them and should not be messed with. And conversely, allowing systems and installation targets *without* package managers to safely manage their Python installations. 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. 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. 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. to have eggs support conformance to the LSB and FHS, 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. 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. Stan Klein ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
On 09/04/2008, Stanley A. Klein [EMAIL PROTECTED] 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. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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 [EMAIL PROTECTED] 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
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
On Wed, Apr 09, 2008 at 02:26:31PM -0400, Stanley A. Klein wrote: 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. Ugh, you have yet to discover the horrors/wonders of MSI (I wish I was as naive as you here!). A properly installed windows program will install using an MSI database, registering each file, registry setting etc. Often a setup.exe will still interface with the MSI database in the background (they should, there's a C API for it too). MSI will even do stuff like reference counting how many programs need a certain file (in case you have something installed in a shared directory), figure out what to do on conflict etc. They have many anc complicated rules, options and features. As far as I am concerned MSI (and thus Add/Remove Programs) can be treated as a package manager in windows. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
On Wed, April 9, 2008 3:40 pm, Phillip J. Eby wrote: 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.) I don't understand what you mean by shared environments and development environments. I also don't know much about Mac OS, except that its underlying Darwin system is a version of BSD (that I assume would follow the Unix FHS). 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. :) I have enough trouble with what I'm already doing. :-) 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. 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. 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. But rpms and debs do include these files, plus manual pages, localization files and a lot of other ancillary stuff. IIRC, you once mentioned that you have a CENTOS system. Do an rpm -qa |sort|less to get an alphabetized list of your installed packages, and then an rpm -qil on some of the packages, and you will see the range of different kinds of files in there. 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. 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. Stan Klein ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
On Wed, April 9, 2008 4:27 pm, [EMAIL PROTECTED] wrote: Message: 5 Date: Wed, 9 Apr 2008 21:21:09 +0100 From: Floris Bruynooghe [EMAIL PROTECTED] Subject: Re: [Distutils] how to easily consume just the parts of eggs thatare good for you To: distutils-sig@python.org On Wed, Apr 09, 2008 at 02:26:31PM -0400, Stanley A. Klein wrote: 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. Ugh, you have yet to discover the horrors/wonders of MSI (I wish I was as naive as you here!). A properly installed windows program will install using an MSI database, registering each file, registry setting etc. Often a setup.exe will still interface with the MSI database in the background (they should, there's a C API for it too). MSI will even do stuff like reference counting how many programs need a certain file (in case you have something installed in a shared directory), figure out what to do on conflict etc. They have many anc complicated rules, options and features. As far as I am concerned MSI (and thus Add/Remove Programs) can be treated as a package manager in windows. I have 3 desktops and a laptop. They are all at least dual boot. One of the systems on each machine is Windows. All the others are Linux, including Fedora 7, Fedora Core 5, Ubuntu 7, or CENTOS 5 in some combination on each machine. My greatest use of Windows is at tax time, because the good tax programs aren't released for Linux. I also have a mid-1990's version of QuickBooks that I still use. Aside from those applications, my use of Windows is sporadic at best, maybe a few times every few months. I do everything else in Linux. My exposure to Windows is minimal, so my exposure to MSI is even less. I wouldn't call it naivete. I just don't do Windows. :-) Stan Klein ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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. :) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
On Apr 9, 2008, at 6:00 AM, Phillip J. Eby wrote: 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. They are easydeb [1] and stddeb [2]. The former appears to be incomplete and unmaintained. The latter appears to be usable, but somewhat incomplete -- substantial manual labor is required to use it successfully, as documented by my programming partner Brian Warner in this ticket: [3]. Regards, Zooko [1] http://easy-deb.sourceforge.net/ [2] http://stdeb.python-hosting.com/ [3] http://allmydata.org/trac/tahoe/ticket/251 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
On 09/04/2008, Stanley A. Klein [EMAIL PROTECTED] 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. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
Stanley A. Klein [EMAIL PROTECTED] 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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
On 09/04/2008, Ben Finney [EMAIL PROTECTED] wrote: Stanley A. Klein [EMAIL PROTECTED] writes: 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. 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? (BTW, it's unreasonable to call Windows legacy - whatever that word means, Windows ain't it (yet...)) Paul. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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, Cheers, Gaël ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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? ;-) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
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. Stan Klein 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. Stan Klein ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
On Tue, April 8, 2008 9:37 pm, Ben Finney [EMAIL PROTECTED] wrote: Date: Wed, 09 Apr 2008 11:37:07 +1000 From: Ben Finney [EMAIL PROTECTED] Subject: Re: [Distutils] how to easily consume just the parts of eggs thatare good for you To: Distutils-Sig@Python.Org zooko [EMAIL PROTECTED] writes: I am skeptical that prorgammers are going to be willing to use a new database format. They already have a database -- their filesystem -- and they already have the tools to control it -- mv, rm, and PYTHONPATH. Many of them already hate the existence the easy_instlal.pth database file, and I don't see why a new database file would be any different. Moreover, many of us already have a database of *all* packages on the system, not just Python-language ones: the package database of our operating system. Adding another, parallel, database which needs separate maintenance, and only applies to Python packages, is not a step forward in such a situation. They both agreed that it made perfect sense. I told one of them about the alternate proposal to define a new database file to contain a list of installed packages, and he sighed and rolled his eyes and said So they are planning to reinvent apt!. That's pretty much my reaction, too. I have the same reaction. I don't install eggs (unless they are installed through my operating system package manager) or use easy_install. My systems have rpms (for Fedora and CENTOS) and debs (for Ubuntu). There are also a Linux Standards Base and a Unix Filesystem Hierarchy Standard (cited by the LSB) that rpms and debs generally enforce, but eggs often do not. I have tried in the past to use easy_install, but have run into problems because there is no communication between easy_install and the rpm database, resulting in failure of easy_install to recognize that dependencies have already been installed using rpms. Also, there are tools provided with rpm and apt to perform functions such as querying installed packages for their contents. I use rpm -qil frequently to find what files a package has installed on my system and where they are installed. A database focused only on Python packages is highly inappropriate for Linux systems, violates the Linux standards, and creates problems because eggs are not coordinated with the operating system package manager. The way to achieve a database for Python would be to provide tools for conversion of eggs to rpms and debs, to have eggs support conformance to the LSB and FHS, and to use rpm or apt for package management. Stan Klein ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] how to easily consume just the parts of eggs that are good for you
At 10:49 PM 4/8/2008 -0400, Stanley A. Klein wrote: On Tue, April 8, 2008 9:37 pm, Ben Finney [EMAIL PROTECTED] wrote: Date: Wed, 09 Apr 2008 11:37:07 +1000 From: Ben Finney [EMAIL PROTECTED] Subject: Re: [Distutils] how to easily consume just the parts of eggs thatare good for you To: Distutils-Sig@Python.Org zooko [EMAIL PROTECTED] writes: eyes and said So they are planning to reinvent apt!. That's pretty much my reaction, too. I have the same reaction. I'm curious. Have any of you actually read PEP 262 in any detail? I have seen precious little discussion so far that doesn't appear to be based on significant misunderstandings of either the purpose of reviving the PEP, or the mechanics of its proposed implementation. I have tried in the past to use easy_install, but have run into problems because there is no communication between easy_install and the rpm database, resulting in failure of easy_install to recognize that dependencies have already been installed using rpms. This problem doesn't exist with Python 2.5, unless you're using a platform that willfully strips out the installation information that Python 2.5 provides for these packages. A database focused only on Python packages is highly inappropriate for Linux systems, violates the Linux standards, and creates problems because eggs are not coordinated with the operating system package manager. The revamp of PEP 262 is aimed at removing .egg files and directories from the process, by allowing system packagers to tell Python what files belong to them and should not be messed with. And conversely, allowing systems and installation targets *without* package managers to safely manage their Python installations. 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. to have eggs support conformance to the LSB and FHS, 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. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] how to easily consume just the parts of eggs that are good for you
Folks: Here is a simple proposal: make the standard Python import mechanism notice eggs on the PYTHONPATH and insert them (into the *same* location) on the sys.path. This eliminates the #1 problem with eggs -- that they don't easily work when installing them into places other than your site-packages and that if you allow any of them to be installed on your system then they take precedence over your non-egg packages even you explicitly put those other packages earlier in your PYTHONPATH. (That latter behavior is very disagreeable to more than a few prorgammers.) This also preserves most of the value of eggs for many use cases. This is backward-compatible with most current use cases that rely on eggs. This is very likely forward-compatible with new schemes that are currently being cooked up and will be deployed in the future. Regards, Zooko ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
