Re: [Python-Dev] how to easily consume just the parts of eggs that are good for you
> > > > IMHO, the main system without a package manager is Windows. > > > > AFAICT the MacOS platform also lacks in this area. > > Actually, they both have them. Windows has Cygwin (rpm-based), while > for MacOS Fink (deb-based), MacPorts (FreeBSD ports-like), and > NetBSD's pkgsrc are all viable options if you want packaging support > for 3rd-party packages. > Er, excuse me for cutting in but-- that's just not at all the same thing. For people who are using a Red Had derivative, or a Debian derivative, or .. whatever .. the package manager isn't something they go out of their way to add and then have to struggle with. It's simply *how* their world works. By a large measure, everything they want is there, managed by their package management system. For those users, I understand well that they don't want some Python package management system to be a second system that they have to deal with. But I'm sorry: the world is bigger then Linux and such things. I'm a mac user, who has had extensive experience in Linux; but on the mac? Fink and MacPorts added on top of MacOSX is not even remotely comparable to using an operating system which has a standard package manager that is a part of every users daily life. My operating system is Unixy, and comes pre-installed with a number of things, including Python, wxWidgets, sqlite-- many things that make the programs I make for my customers easy to use. But for those products that are *not* available standard, where are my mac customers left? Their options are to install something like Fink, or MacPorts... and then we come into issues of it wanting to install its *own* version of python, or its *own* version of these third party things, on top of what's already there? The alternative is that users have to install, manually, these third-party requirements themselves. I've found that it is in general far easier for me to just download and install stuff manually then to rely on these "Add-on" package managers. At least if I'm thinking of providing as minimally and least intrusive as possible experience for my users to install my product. Power users, especially those familiar with the Linux world, may relish in the existence of MacPorts and Fink... Regular people, even IT managers of companies I have to deal with-- will not. I love easy_install/setuptools because it lets me get my *Python* applications and products out to people, regardless of OS, in a way that just *works*. I do think its valuable to do so in a way that will integrate with native package managers on those operating systems that they are a native and integrated part of -- but to say, "Let's not re-create apt!" is a sorrowful stance. It's saying, "Screw Windows, because it isn't as good as what we have." and "Screw Mac, because its not as good as we have." Or even, "Screw the people who aren't power users and are just not going to be able to go through the effort of adding *on* a non-standard package management system to their operating system." There's a whole wide world out there that simply does *not* have a "package management"(*) system. Python is beautiful, making Python programs is blissful. I'd be far, far more concerned with making it easy to distribute Python-based programs to *any* operating system then I would be concerned with partially redoing what a *minority* of systems out there have done to make package management (with dependencies and all) easy for its users. Python is a cross-platform development environment. Let's not forget that most people just... don't have Linux... and don't have the equally blissful world of apt or rpm available to them natively. Its very cool to *integrate* -- to make a way for those RPM and DEB distributors to deliver an app in their own way that will satisfy their needs. But what about the people *without* that native capability? Having a Python-only distribution/management system like easy_install is a *huge* boon to getting real products to real people. I think PJE's idea here is very good. Just include certain files and such in the RPM/DEB that will satisfy the "python-package-management" system. For RPM/DEB users and their OS's database of packages, its irrelevant largely-- they'll still keep using their own system. But if a product needs something without a .deb or .rpm, or if someone's on an operating system without a native system-- they can still gather everything they need. Anyways. My 2 cents. --Stephen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Distutils] how to easily consume just the parts of eggs that are good for you
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). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] how to easily consume just the parts of eggs that are good for you
Stephen Hansen writes: > > > > > > IMHO, the main system without a package manager is Windows. > > > > > > AFAICT the MacOS platform also lacks in this area. > > > > Actually, they both have them. Windows has Cygwin (rpm-based), while > > for MacOS Fink (deb-based), MacPorts (FreeBSD ports-like), and > > NetBSD's pkgsrc are all viable options if you want packaging support > > for 3rd-party packages. > > Er, excuse me for cutting in but-- that's just not at all the same > thing. [...] > I do think its valuable to do so in a way that will integrate with native > package managers on those operating systems that they are a native and > integrated part of Why restrict it to those? That's my point. If you're going to make it apt-compatible, you should do all the others, too, because there are lots of people using them. Whether or not they are OS-provided. As far as I'm concerned, asking a Python tool to integrate into any pms is a non-starter because it really means asking for integration into all of them. > but to say, "Let's not re-create apt!" is a sorrowful stance. It's > saying, "Screw Windows, because it isn't as good as what we have." > and "Screw Mac, because its not as good as we have." It's worse than that. One point I hoped to make is that "Let's not recreate apt!" is a way of saying "Screw Windows and Mac and Red Hat and Gentoo and NetBSD and FreeBSD and " I think it's worth working out a standard format for documenting dependencies so that a downstream distributor can easily create a dependency graph (perhaps several of them, since system bootstrap, package build-time, and package run-time may have different requirements). And standard Python distribution media should have a "manual mode" so that distros can decide where to put things. But that's as far as Python itself should ever go; fitting those things into any given pms is the downstream distro's job. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] how to easily consume just the parts of eggs that are good for you
At 12:12 AM 4/10/2008 -0700, Stephen Hansen wrote: >I think PJE's idea here is very good. Just include certain files and >such in the RPM/DEB that will satisfy the >"python-package-management" system. For RPM/DEB users and their OS's >database of packages, its irrelevant largely-- they'll still keep >using their own system. But if a product needs something without a >.deb or .rpm, or if someone's on an operating system without a >native system-- they can still gather everything they need. I've narrowed it a bit from that, actually. It's safest if easy_install simply refuses to touch any files that it can't tell were installed by it (or a compatible system, eg. distutils.) While that won't solve Paul Moore's desire for the One True Package Manager, it will at least make it possible to move forward. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Next monthly sprint/bugfix day?
On Wed, Apr 09 2008 at 11:12:58AM BRT, Trent Nelson <[EMAIL PROTECTED]> wrote: > Hi, > > Is there another online sprint/bugfix day in the pipeline? If not, can > there be? ;-) +1. The Sao Paulo User's Group gathered to work on the last Bug Day, and I think it was very productive (both for generating patches/comments and for us to get more involved with Python core development). So, actually, assuming I can speak for at least half of the people from the PUG who participated in the last Bug Day, +~8 :). rbp -- Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> | GPG: <0x0DB14978> ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling Python on a biarch (PPC/PPC64)
Hi Martin, On Wed, 2008-04-09 at 23:27 +0200, "Martin v. Löwis" wrote: > > Can anyone give me a hand on this? As far as I could > > investigate, I must change setup.py in order to get this issue fixed, > > right? > > Wrong. I didn't read your entire message, but this is definitely wrong. > setup.py isn't invoked until python itself is built, and > Modules/python.c is part of python itself. If I understood correctly, you're saying that Python's building process involves only the C compiler, right? So, in order to fix this issue that I've found, I only need to modify configure.in file (and maybe Makefile.pre.in). Is that correct? Regards, -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling Python on a biarch (PPC/PPC64)
> If I understood correctly, you're saying that Python's building process > involves only the C compiler, right? So, in order to fix this issue that > I've found, I only need to modify configure.in file (and maybe > Makefile.pre.in). Is that correct? Correct. There are also some additional shell scripts involved, but I don't think they matter. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] generated NEWS files
I know that doing merges is rather painful because of the Misc/NEWS files. Would it be possible to have the NEWS log generated from commit messages? I was thinking something like this in a message: Fixed this and that **NEWS:Library** #1234 X is now known as Y. It should be fairly simple to write a script to extract and compile these messages into NEWS before release. -- Cheers, Benjamin Peterson ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] generated NEWS files
In the past we haven't done that because often the change logs are either too chatty (they do administrative stuff that doesn't deserve a NEWS entry) or they are too brief (in the heat of the battle developers don't always write great changelog entries). While it's easy to fix NEWS its not easy to fix changelog entries (only a few svn super-users can do it, and it's a pain). --Guido On Thu, Apr 10, 2008 at 4:42 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > I know that doing merges is rather painful because of the Misc/NEWS > files. Would it be possible to have the NEWS log generated from commit > messages? I was thinking something like this in a message: > > Fixed this and that > > **NEWS:Library** > #1234 X is now known as Y. > > It should be fairly simple to write a script to extract and compile > these messages into NEWS before release. > > -- > Cheers, > Benjamin Peterson > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] generated NEWS files
On Thu, Apr 10, 2008 at 7:55 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > In the past we haven't done that because often the change logs are > either too chatty (they do administrative stuff that doesn't deserve a > NEWS entry) or they are too brief (in the heat of the battle > developers don't always write great changelog entries). While it's > easy to fix NEWS its not easy to fix changelog entries (only a few svn > super-users can do it, and it's a pain). A NEWs entry wouldn't be added if the special **NEWS** marking wasn't present. I think we'd have to come up with some way to let people change/edit by overriding those in the commit messages, but I'm not sure how that would be done. > > --Guido -- Cheers, Benjamin Peterson ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] generated NEWS files
On Thu, Apr 10, 2008 at 5:59 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 7:55 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > In the past we haven't done that because often the change logs are > > either too chatty (they do administrative stuff that doesn't deserve a > > NEWS entry) or they are too brief (in the heat of the battle > > developers don't always write great changelog entries). While it's > > easy to fix NEWS its not easy to fix changelog entries (only a few svn > > super-users can do it, and it's a pain). > A NEWs entry wouldn't be added if the special **NEWS** marking wasn't > present. I think we'd have to come up with some way to let people > change/edit by overriding those in the commit messages, but I'm not > sure how that would be done. It would be fine if that was *one* way of adding a NEWS entry, but I don't think it should be the only way, and I don't think it would work well to regenerate the NEWS file from those entries. In practice we see corrections on NEWS entries all the time. Also, there's the issue of which section of the NEWS file an entry should be added. That's often subjective. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] generated NEWS files
On Thu, Apr 10, 2008 at 6:24 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Also, there's the issue of which section of the NEWS file an entry > should be added. That's often subjective. > Agreed. For example we have both Library and Extension Module categories in the NEWS file. I always end up listing changes in the "wrong" one of those half the time. In my mind those are the same thing. A reader is not likely to care if the change happened to be implemented in the Lib/ directory vs the Modules/ directory. From python's point of view they're both just an import. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
