Re: [Python-Dev] Python source code on Bazaar vcs
(To provide counterweight.) -On [20080320 20:44], Barry Warsaw ([EMAIL PROTECTED]) wrote: >We have not made a decision to move to Bazaar officially, nor have we made >a decision to even move off of Subversion. Good, because between this now and pytz the other 63 projects I follow use Subversion or Mercurial. Bazaar seems to be mostly limited to Ubuntu users and stuff Canonical does, so the choice for a Bazaar setup next to Subversion strikes me a bit as odd. Mercurial is also Python, distributed and with a, as far as I (can) track things, bigger market share than Bazaar. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ The fragrance always stays in the hand that gives the rose... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python source code on Bazaar vcs
Sorry for the double post, Jeroen :| -- Forwarded message -- From: Matthieu Brucher <[EMAIL PROTECTED]> Date: 21 mars 2008 10:03 Subject: Re: [Python-Dev] Python source code on Bazaar vcs To: Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> 2008/3/21, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]>: > > (To provide counterweight.) > > > -On [20080320 20:44], Barry Warsaw ([EMAIL PROTECTED]) wrote: > >We have not made a decision to move to Bazaar officially, nor have we > made > >a decision to even move off of Subversion. > > > Good, because between this now and pytz the other 63 projects I follow use > Subversion or Mercurial. > Bazaar seems to be mostly limited to Ubuntu users and stuff Canonical > does, > so the choice for a Bazaar setup next to Subversion strikes me a bit as > odd. > Mercurial is also Python, distributed and with a, as far as I (can) track > things, bigger market share than Bazaar. > Hi, This is not quite true. One of the main bzr developers is a Windows guy, so the user base is/will be large, far larger than only Ubuntu. A lot of projects switched to bzr because of this. Honestly, I think that Hg and bzr fill the same need, but bzr developement at the moment is fantastic. For a still young product it is a good think (Hg is older). One additional good think is that there is a Sourceforge-like site that uses bzr ; launchpad.net. I don't know of something equivalent for Hg. Just my two (euro) cents ;) Matthieu -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: from __future__ import unicode_string_literals
Eric Smith wrote: > This proposal is to add "from __future__ import > unicode_string_literals", which would make all string literals in the > importing module into unicode objects in 2.6. I'm going to withdraw this, for 2 reasons. 1) The more I think about it, the less sense it makes. 2) Without some extreme measures, it's not implementable. It's not implementable because the work has to occur in ast.c (see Py_UnicodeFlag). It can't occur later, because you need to skip the encoding being done in parsestr(). But the __future__ import can only be interpreted after the AST is built, at which time the encoding has already been applied. There are some radical things you could do to work around this, but it would be a gigantic change. As for it not making sense, this is really in the realm of 2to3. I'm beginning to really believe this statement in PEP 3000: "There is no requirement that Python 2.6 code will run unmodified on Python 3.0. Not even a subset. (Of course there will be a tiny subset, but it will be missing major functionality.)" For this particular issue, just use u'' in 2.6 and let 2to3 deal with it. If you have some 2.6 code that you want to run in 3.0 (by way of 2to3), I think all of your string literals should either be b'' or u''. Don't use plain ''. Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)
On 21/03/2008, Terry Reedy <[EMAIL PROTECTED]> wrote: > However, this Windows user, and I expect most, do NOT expect add-ons > (things under the /Pythonx.y tree) to show up in the add/remove list. That's an interesting counterpoint to my comments. I presume from this that you dislike (and/or never use) bdist_msi and bdist_wininst precisely because they do add such items to the add/remove programs list? My argument is essentially that bdist_wininst set a de facto standard for this. Then, bdist_msi followed it. Now setuptools is trying to change that standard by ignoring it, rather than by discussion of the pros and cons. Personally, I like the current approach, but that's less relevant. > The standard (and to me, preferable) way of dealing with such things is to > have an 'installation manager' that can reinstall as well as delete and > that has a check box for various things to delete. This is what Python > needs. I'd dispute strongly that this is a "standard". It may be preferable, but I'm not sure where you see evidence of it being a standard. Could I also point out that *if* such a standard is set up for Python, bdist_wininst and bdist_msi should be modified to follow it. Otherwise, it's not a standard, more of competing approach. As you can see, my main concern is for consistency :-) Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)
At 12:33 PM 3/21/2008 +, Paul Moore wrote: >On 21/03/2008, Terry Reedy <[EMAIL PROTECTED]> wrote: > > The standard (and to me, preferable) way of dealing with such > things is to > > have an 'installation manager' that can reinstall as well as delete and > > that has a check box for various things to delete. This is what Python > > needs. > >I'd dispute strongly that this is a "standard". It may be preferable, >but I'm not sure where you see evidence of it being a standard. I presume he means that there are a lot of entries in his Add/Remove Programs that work like that, and that it's an emerging standard for Windows. (Certainly I've seen quite a few entries like that in mine, although more often than not they only have one checkbox!) >Could I also point out that *if* such a standard is set up for Python, >bdist_wininst and bdist_msi should be modified to follow it. >Otherwise, it's not a standard, more of competing approach. The best thing to do would be to get a standard (ala PEP 262, but modified by the benefit of experience now) for tracking installed Python package distributions. Then we can standardize on platform tools for managing this data, and include them in the relevant platform distributions. (And that would include making bdist_wininst and bdist_msi follow this installation DB standard.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python source code on Mercurial
Ralf Schmitt gmail.com> writes: > > I have also setup a mirror using mercurial: http://hgpy.de/py/It contains the 2.4, 2.5, trunk and py3k branches (in case anyone wants to compare this to bzr). I see your trunk history is stripped. For those who want the complete trunk history (back to 17 years ago!), I have my own mirror here: http://dev.pitrou.net:8000/cpython/trunk/ For Mercurial beginners, you just have to install Mercurial and type: hg clone http://dev.pitrou.net:8000/cpython/trunk/ This gives you a local repository in the "trunk" directory which includes all the pulled history from the said mirror. (however, please note the server is not mine, and I do not guarantee the above URL will function forever :-)) Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)
-On [20080320 19:24], Steve Holden ([EMAIL PROTECTED]) wrote: >We need to stop protesting that our installation tools are easy enough >and try to get behind the various platforms, be it with Windows >installers, rpms, or other support. We probably aren't doing this >because it's work nobody particularly relishes, and has relatively low >visibility in the developer world. Non-developer Python programmers and >end-users would thank us, though. FreeBSD offers through install of Perl through its ports system a Perl module called 'bsdpan' which registers every module as a package under FreeBSD's package system. Normally ports installs modules as p5-ModuleName, but now it becomes: /var/db/pkg/bsdpan-B-Lint-1.09 And from that point on I can use the pkg* tools. Quite elegant in my opinion. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ To regard the fundamental as the essence, to regard things as coarse, to regard accumulation as deficiency, and to dwell quietly alone with the spiritual and the intelligent -- herein lie the techniques of Tao of the ancients. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] How we can get rid of eggs for 2.6 and beyond
So, after having some time to absorb the Python-Dev threads about
setuptools, bootstrap, and all the rest, I think I see an opportunity
to let people route around the "damage" of eggs, while still making
it possible for the people who want to use easy_install or to put
dependencies in their setup.py to get what they want, too. (And
without them needing to install eggs, either.) At the same time, we
can address the issues that remain around uninstalling packages,
system vs. user packages, PYTHONPATH and site.py woes, and really
pretty much every other complaint I've heard in the last few days
about setuptools stomping on other people's stuff. (Even Paul's
Windows issues, hopefully.)
Now, you might be asking, "Okay, so why are you telling me about
this? Why not just go fix setuptools?" Well, I *can't*. Not
without some help from Python-Dev and the Distutils-SIG, to create an
updated standard for installed package metadata, by updating PEP 262
("A Database of Installed Python Packages") to include input from the
system packaging folks, support for namespace packages, and support
for setuptools-compatible dependency information.
What's that got to do with anything? Well, without it, setuptools
can't support uninstall or conflict management without using eggs to
compartmentalize the installed files. And because it has to use eggs
to do *that*, it has to munge .pth files and install its own site.py
when installing to PYTHONPATH. All of this ugliness follows directly
from the absence of a PEP 262-style installation database.
Sure, setuptools could create its own version of this, and I almost
did that four years ago. (If you look at the "open issues" part of
PEP 262, you'll see my comments from back then.) I decided not to
for two reasons: first, the distutils didn't support it yet, so it
didn't help for conflict detection and avoidance in the real world at
that point.
Second, there were no uninstall tools for it, so I'd have had to
write one myself. (Zed's "easy_f'ing_uninstall" to the contrary, it
ain't easy, and I have an aversion to deleting stuff on people's
systems without knowing what will break. There's a big difference
between them typing 'rm -rf' themselves, and me doing it.)
However, if tools exist and are distributed for such a "database",
and *everybody* agrees to use it as an officially-blessed standard,
then it should be possible for setuptools to co-exist with that
framework, and we're all happy campers.
In particular, the "installing eggs sucks" camp should be happy,
because it'll be possible for me (or anyone else) to write a version
of easy_install that doesn't install eggs any more, and
setuptools-based packages can go back to having "setup.py install"
install things the old way by default.
So, to accomplish this, we (for some value of "we") need to:
1. Hash out consensus around what changes or enhancements are needed
to PEP 262, to resolve the previously-listed open issues, those that
have come up since (namespace packages, dependency specifications,
canonical name/version forms), and anything else that comes up.
2. Update or replace the implementation as appropriate, and modify
the distutils to support it in Python 2.6 and beyond. And "support
it" means, "ensure that 'install' and *all* bdist commands update the
database". The bdist_rpm, bdist_wininst, and bdist_msi commands,
even bdist_dumb. (This should probably also include the add/remove
programs stuff in the Windows case.)
3. Create a document for system packagers referencing the PEP and
introducing them to what/why/how of the standard, in case they
weren't one of the original participants in creating this.
It will probably take some non-trivial work to do all this for Python
2.6, but it's probably possible, if we start now. I don't think it's
critical to have an uninstall tool distributed with 2.6, as long as
there's a reasonable way to bootstrap its installation later.
Questions, comments... volunteers? :)
___
Python-Dev mailing list
[email protected]
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 we can get rid of eggs for 2.6 and beyond
Phillip J. Eby wrote: > Second, there were no uninstall tools for it, so I'd have had to > write one myself. (Zed's "easy_f'ing_uninstall" to the contrary, it > ain't easy, and I have an aversion to deleting stuff on people's > systems without knowing what will break. There's a big difference > between them typing 'rm -rf' themselves, and me doing it.) > I think, the uninstall should _not_ 'rm -rf' but only 'rm' the files (and 'rmdir' directories, but not recursively) that it created, and that have not been modified in the meantime (after the installation). This can be easily achieved by recording a checksum (eg. md5 or sha) upon installation and only deleting a file if the checksum is correct and only deleting directories when they are empty (after the installed files in them have been deleted). Otherwise, the uninstall should complain and leave the modified files installed. Joachim ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
On Fri, Mar 21, 2008 at 2:47 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > Second, there were no uninstall tools for it, so I'd have had to > write one myself. (Zed's "easy_f'ing_uninstall" to the contrary, it > ain't easy, and I have an aversion to deleting stuff on people's > systems without knowing what will break. There's a big difference > between them typing 'rm -rf' themselves, and me doing it.) > Agree. I tried a while ago to write a "easy_uninstall" but this is not possible from an application-point of view, to do clean things. zc.buildout resolves this by installing eggs locally, to an isolated environment, so my main Python installation doesn't hold any extensions at all. So if a database of installed package is created, I would be in favor of an application-oriented system where it is possible to create, update, install, a set of packages dedicated to an environment (default would be Python). Maybe by having a namespace tied to a list of versions. In other words; having the same feature virtualenv provides, in Python itself, and define somehow how to switch to it. $ easy_install the.package --environment MyApp ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Wow, I think I actually *get* it now!
Phillip J. Eby wrote: > Hm. So it seems to me that maybe one thing that would help is a > "Setuptools Haters' Guide To Setuptools" -- that is, *short* > documentation specifically written for people who don't want to use > setuptools and want to minimize its impact on their systems. Perhaps relevant are my blog entries on how to use setuptools with GNU stow: https://zooko.com/log-2007.html#d2007-04-27- distutils_or_setuptools_with_GNU_stow https://zooko.com/log-2007.html#d2007-06-02- distutils_or_setuptools_with_GNU_stow Regards, Zooko ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)
On Mar 20, 2008, at 6:22 PM, Robert Brewer wrote: > Phillip J. Eby wrote: >> The other tool that would be handy to have, would be one that unpacks >> eggs into standard distutils-style installation. > > Hear, hear. I'm an author of a couple libraries that need to > interoperate with others. Of the many eggs I've downloaded over the > past > year, I'd say 80%+ are never installed or even built--I just want to > grep the source code, and using my preferred tools, not some lame Find > command in a ZIP browser menu. Um, isn't this tool called "unzip"? I have done this -- accessed the source code -- many times, and unzip suffices. I don't know what else would be required in order to make an egg into "a standard distutils-style installation". Until PJE's comment above, I thought that unzip already accomplished exactly that. Regards, Zooko ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the Joachim> files (and 'rmdir' directories, but not recursively) that it Joachim> created, and that have not been modified in the meantime (after Joachim> the installation). That's not sufficient. Suppose file C (e.g. /usr/local/etc/mime.types) is in both packages A and B. Install A - this will create C Install B - this might overwrite C, saving a copy, or it might retain A's copy. Uninstall B - this has to know that C is used by A and not touch it Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)
At 09:53 AM 3/21/2008 -0600, zooko wrote: >Um, isn't this tool called "unzip"? I have done this -- accessed the >source code -- many times, and unzip suffices. > >I don't know what else would be required in order to make an egg into >"a standard distutils-style installation". You also have to rename the EGG-INFO directory to a .egg-info file of the same basename as the original .egg; otherwise, pkg_resources and other runtime access to the egg won't know it's installed. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
On 20 Apr, 2006, at 22:07, Martin v. Löwis wrote: Guido van Rossum wrote: This is another area where API standardization is important; as soon as modules are loaded out of a zip file, the traditional approach of looking relative to os.path.dirname(__file__) no longer works. 2. standardize on file names, not API. If I want to deploy read-only data files, I put them into /usr/share. If I need read-write files, I put them into /var. I did not have such a problem yet on other systems, but I would also try to follow the conventions of these systems. I don't think anyone mentioned this, but part of pkg_resources is an API for loading package-related data. That currently looks for data near the code, which makes Linux packagers unhappy but it should be possible to enhance pkg_resources to look in other locations (such as a directory below /usr/share/python) as well. The data loading API's is one feature of pkg_resources that would make it easier to locate data while at the same time storing data in locations that the various platforms proscribe without hardcoding such knowledge into every program. BTW. Please keep in mind that one of the major platforms for python doesn't have a proper package manager at all. OSX does have an installer application, but that's just that: a GUI for dropping files on you disk. There is no uninstaller, and no real dependency management. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
Phillip J. Eby schrieb: > Questions, comments... volunteers? :) I've yet to read the monster package utils thread so I can't comment on it. However I like to draw some attention to my PEP 370 http://python.org/dev/peps/pep-0370/. It's about a site packages directory in the users home directory. I think it quite related to the discussion. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: from __future__ import unicode_string_literals
Eric Smith schrieb: > It's not implementable because the work has to occur in ast.c (see > Py_UnicodeFlag). It can't occur later, because you need to skip the > encoding being done in parsestr(). But the __future__ import can only > be interpreted after the AST is built, at which time the encoding has > already been applied. There are some radical things you could do to > work around this, but it would be a gigantic change. So this basically comes down to "Either spend lots of time (and money) to rewrite the tokenizer and AST generator or keep the current behavior"? :/ > For this particular issue, just use u'' in 2.6 and let 2to3 deal with > it. If you have some 2.6 code that you want to run in 3.0 (by way of > 2to3), I think all of your string literals should either be b'' or u''. > Don't use plain ''. For this particular issue one could probably and easily come up with a fast fixer. A simple regexp should be cover 99% of all occurrences of u'' and u"". Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: from __future__ import unicode_string_literals
Christian Heimes wrote: > Eric Smith schrieb: > > It's not implementable because the work has to occur in ast.c (see >> Py_UnicodeFlag). It can't occur later, because you need to skip the >> encoding being done in parsestr(). But the __future__ import can only >> be interpreted after the AST is built, at which time the encoding has >> already been applied. There are some radical things you could do to >> work around this, but it would be a gigantic change. > > So this basically comes down to "Either spend lots of time (and money) > to rewrite the tokenizer and AST generator or keep the current behavior"? :/ Pretty much. And even if it were possible, I don't see the point in doing it. >> For this particular issue, just use u'' in 2.6 and let 2to3 deal with >> it. If you have some 2.6 code that you want to run in 3.0 (by way of >> 2to3), I think all of your string literals should either be b'' or u''. >> Don't use plain ''. > > For this particular issue one could probably and easily come up with a > fast fixer. A simple regexp should be cover 99% of all occurrences of > u'' and u"". 2to3 already does this. My current thinking is that only b'' and u'' strings should be in 2.6 code that you want to move to 3.0. Maybe -3 should warn about regular string literals? ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
[EMAIL PROTECTED] writes: > > Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the > Joachim> files (and 'rmdir' directories, but not recursively) that it > Joachim> created, and that have not been modified in the meantime (after > Joachim> the installation). > > That's not sufficient. Suppose file C (e.g. /usr/local/etc/mime.types) is > in both packages A and B. > > Install A - this will create C > Install B - this might overwrite C, saving a copy, or it might retain > A's copy. > Uninstall B - this has to know that C is used by A and not touch it MacPorts has an expensive but interesting approach. When it finds a file used by another package, it backs it up to sth like $file.`date`. ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
At 11:21 AM 3/21/2008 -0500, [EMAIL PROTECTED] wrote: > Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the > Joachim> files (and 'rmdir' directories, but not recursively) that it > Joachim> created, and that have not been modified in the meantime (after > Joachim> the installation). > >That's not sufficient. Suppose file C (e.g. /usr/local/etc/mime.types) is >in both packages A and B. > > Install A - this will create C > Install B - this might overwrite C, saving a copy, or it might retain > A's copy. > Uninstall B - this has to know that C is used by A and not touch it Correct. However, in practice, B should not touch C, unless the file is shared between them. This is a key issue for support of namespace packages, at least if we want to avoid using .pth files. (Which is what setuptools-built system packages do for namespace packages currently.) Of course, one possible solution is for both A and B to depend on a "virtual package" that contains C, such that both A and B can install it if it's not there, and list it in their dependencies. But this is one of the handful of open issues that needs to be resolved with Real Life Package Management people, such as Debian, Fedora, etc. Neither overwriting, refusing to install, nor backups will properly address this issue. However, this is properly a topic for the Distutils-SIG or whatever SIG the actual spec goes to. On Python-Dev I'm only looking for a go/no-go on the overall approach. ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
On 2008-03-21 14:47, Phillip J. Eby wrote: > So, to accomplish this, we (for some value of "we") need to: > > 1. Hash out consensus around what changes or enhancements are needed > to PEP 262, to resolve the previously-listed open issues, those that > have come up since (namespace packages, dependency specifications, > canonical name/version forms), and anything else that comes up. > > 2. Update or replace the implementation as appropriate, and modify > the distutils to support it in Python 2.6 and beyond. And "support > it" means, "ensure that 'install' and *all* bdist commands update the > database". The bdist_rpm, bdist_wininst, and bdist_msi commands, > even bdist_dumb. (This should probably also include the add/remove > programs stuff in the Windows case.) The bdist commands don't need to touch that database in any way, since they don't install anything, nor do they upload things anywhere. They simply package code and put the result into the dist/ subdir. That's all. What you probably mean is that the installers, pre/post-scripts, etc. run when installing one of those packages should update the database of installed packages. Note that there are several package formats which do not execute any code when installing them - the user simply unzips them in some directory. These packages won't be able to register themselves with a database. I guess the only way to support all of these variants is to use a filesystem based approach, e.g. by placing a file with a special extension into some dir on sys.path. The "database" logic could then scan sys.path for these files, read the data and provide an interface to it. All bdist formats would then have to include these files. distutils already writes .egg-info files when running python setup.py install, so perhaps that's a start (though I'd prefer a three letter extension such as ".pkg"). .egg-info files currently only include the package meta-data (the PKG-INFO section from PEP 262). We'd have to add a list of files making up the package (FILES section in PEP 262) and also some extra information about any extra files the package creates that can safely be removed in the uninstall process (e.g. .pyo and .pyc files, temporary files, database files, configuration data, registry entries, etc.) - this is currently not covered in PEP 262. I don't think the REQUIRES and PROVIDES sections from the PEP 262 are needed. That info can easily go into the PKG-INFO section. A separate FILES section also doesn't seem to be necessary - we could just add one or more entries or the format: CreatesDir abc/ CreatesFile abc/xyz1.py CreatesDir abc/def/ CreatesFile abc/def/xyz2.py CreatesFile abc/def/xyz3.py CreatesFile abc/def/xyz4.ini (BTW: wininst writes such a file for the uninstall process) So to keep things simple, the rfc822 approach defined in PEP 241 would easily cover everything needed and we could trim down the PEP 262 format to a simple rfc822 header list. In other words: the .egg-info files already provide the basis and only need to be extended with a list of created files, directories (and possibly other resources) as well as a list of resources which may be removed even if not installed explicitly such as byte-code files, etc. > 3. Create a document for system packagers referencing the PEP and > introducing them to what/why/how of the standard, in case they > weren't one of the original participants in creating this. This should probably be a new PEP defining all the bits and pieces making up the installation "database". > It will probably take some non-trivial work to do all this for Python > 2.6, but it's probably possible, if we start now. I don't think it's > critical to have an uninstall tool distributed with 2.6, as long as > there's a reasonable way to bootstrap its installation later. BTW: There's a simple uninstall command in mxSetup.py that we could contribute to distutils. It works much in the same way as the install command... except that it removes all the files it would have installed. Using pre-built packages, this works without having to rebuild the package just to be able to determine the list of things that need to be removed. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 21 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/
Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] To Paul's question: I have only installed a couple of things (and not recently) that added their own add/remove entry. But I am not sure I would have called them add-ons as opposed to independent applications written in Python. | I presume he means that there are a lot of entries in his Add/Remove | Programs that work like that, and that it's an emerging standard for | Windows. (Certainly I've seen quite a few entries like that in mine, | although more often than not they only have one checkbox!) Yes. At least half my experience with uninstalls is removing games. Recent games typically have separate boxes for various things such as games files, save files, mods, game directory and any user added content, and icons and registry entries. Most Python add-ons I have downloaded are unziped to site-packages and only a few megabytes in size (versus gigabytes for some games). Hence there is little need to uninstall them (unless dumping everything connected with pyx.y, which is easy). Hence no desire to have add/remove slowed down and cluttered with dozens of entries for such things. I admit that my wish for a better installation manager is something I can only help with on the surface by expressing desires and testing results as a practice user. tjr ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
Phillip J. Eby wrote: > Questions, comments... volunteers? :) This makes a lot of sense. I don't really have anything to add in terms of implementation, but I wonder if we can learn something from how apt or rpms or ports work, and how other programming languages (Ruby gems?) solve this. It's not an easy problem space since you're dealing with disparate and inconsistent target platforms, but it's one that has been solved before by others. Cheers, Martin ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
On 21/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > Questions, comments... volunteers? :) Sounds good. I won't volunteer as I have neither time nor expertise to contribute much. But I'd like to see this happen, as it sounds like it would address all my issues with setuptools (and just to reiterate, I'm happy if it is implemented *in place of* add/remove programs - I have no vested interest in that facility as such). For uninstall support, you might look at how bdist_wininst installers handle it. In my experience the uninstall is robust, clean, and reliable, and the supporting metadata is pretty simple (just a text file). Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] SVN FAQ for Windows users
I noticed that http://www.python.org/dev/faq/#how-do-i-apply-a-patch ...does not contain instruction for Windows user willing to apply a patch starting from a .diff file. Since Tortoise SVN is the most common choice I tried to describe the steps to apply a patch by using it. This could be added in the same section (5.2) righ after the UNIX instructions. --- snippet --- If you're using Windows make sure you have TortoiseSVN installed. Right-click on the folder containing the trunk source code, expand the TortoiseSVN submenu and select 'Apply Patch...'. Browse to the patch file and select it, then right click on the file appearing in the 'File Patches' window and click on 'Patch selected'. After you're done, close the TortoiseMerge window. --- /snippet --- Hope this helps. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SVN FAQ for Windows users
Thanks Giampaolo! Totally unrelated to your posting: I wonder why http://www.python.org/dev/faq/#how-to-make-a-patch uses tee instead of > file ? Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python source code on Bazaar vcs
On Fri, Mar 21, 2008 at 1:42 AM, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > (To provide counterweight.) > > > -On [20080320 20:44], Barry Warsaw ([EMAIL PROTECTED]) wrote: > >We have not made a decision to move to Bazaar officially, nor have we made > >a decision to even move off of Subversion. > > Good, because between this now and pytz the other 63 projects I follow use > Subversion or Mercurial. > Bazaar seems to be mostly limited to Ubuntu users and stuff Canonical does, > so the choice for a Bazaar setup next to Subversion strikes me a bit as odd. > Mercurial is also Python, distributed and with a, as far as I (can) track > things, bigger market share than Bazaar. > Just to head this off, this is not a specific vote of confidence for Bazaar. The Bazaar developers were at PyCon and both Barry and Thomas were willing to put the time and effort to get the mirror up and going while the Bazaar team was nearby to answer questions. At this point this is more of an experiment to see if people like the development style of distributed VCS. If people do and someone steps forward to put the time and effort to add Mercurial support, we can then consider doing something similar to what was done for the issue tracker. But for right now this is just to try out distributed VCS, nothing more. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python source code on Bazaar vcs
On Thu, Mar 20, 2008 at 2:42 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I'm happy to announce that we now have available for public > consumption, the Python source code for 2.5, 2.6 and 3.0 available > under the Bazaar distributed version control system. > > The current Subversion repository is still the master copy of the > source code. We have not made a decision to move to Bazaar > officially, nor have we made a decision to even move off of > Subversion. We're making these branches available exactly so that > you, the Python developer community, can kick the tires and see if it > makes sense to move to a different vcs. Nothing will happen until > after the Python 2.6/3.0 releases anyway. > > All the gory details are documented here: > > http://www.python.org/dev/bazaar > > These branches are available both for core Python developers with > commit privileges, and the wider world of developers without commit > privileges. It's this latter group that I think will find the most > compelling immediate benefit from using Bazaar, because they will no > longer need to maintain their own changes using a mass of patch files. > > For more information on Bazaar in general, see: > > http://bazaar-vcs.org > > You will probably be most interested in the Bazaar mirrors of the > Subversion master repository. We have a cron job that updates Bazaar > from Subversion every 15 minutes. It is also possible to push changes > made in your Bazaar branches into the Subversion master, so you can > keep reasonably up-to-date and interact with the Python source code > solely via Bazaar. Great work! I love Bazaar. It's a lot more flexible and user-friendlier than anything else out there. I hope we can switch to Bazaar entirely sometime! :) > > > Please let me know if you have any questions or anything in the docs > referenced above aren't clear. I know I need to document the Bazaar- > >Subversion workflow in more detail. > > Huge thanks go out especially to Thomas Wouters who sprinted with me > yesterday on getting the whole infrastructure up and running. Thanks > also to Martin v. Loewis, Sean Reifschneider, and the folks here at > Pycon from the Bazaar project, Ian, Andrew, John, and Edwin. > > Enjoy, > - -Barry > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.8 (Darwin) > > iQCVAwUBR+K+H3EjvBPtnXfVAQL6bwP/d0XKx0mRPgzdOD6zCPwwRl8y2kxWV9Vl > zVwN07cK8IlwMa9M470MsERuXuD8hmeXnPgnrUcrX9HciwldmY8C33t0f8GaOk1J > iD4Od1midlIaJJiMd+JcFk9NbX3Rwc4HMj3s8jKjjdlGrFe77ei9DCZ/HMl/iG5K > fyyjXo4HLEE= > =Gcjq > -END PGP SIGNATURE- > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: from __future__ import unicode_string_literals
On Fri, Mar 21, 2008 at 11:06 AM, Eric Smith <[EMAIL PROTECTED]> wrote: > Christian Heimes wrote: > > Eric Smith schrieb: > > > It's not implementable because the work has to occur in ast.c (see > >> Py_UnicodeFlag). It can't occur later, because you need to skip the > >> encoding being done in parsestr(). But the __future__ import can only > >> be interpreted after the AST is built, at which time the encoding has > >> already been applied. There are some radical things you could do to > >> work around this, but it would be a gigantic change. > > > > So this basically comes down to "Either spend lots of time (and money) > > to rewrite the tokenizer and AST generator or keep the current behavior"? > :/ > > Pretty much. And even if it were possible, I don't see the point in > doing it. > > > >> For this particular issue, just use u'' in 2.6 and let 2to3 deal with > >> it. If you have some 2.6 code that you want to run in 3.0 (by way of > >> 2to3), I think all of your string literals should either be b'' or u''. > >> Don't use plain ''. > > > > For this particular issue one could probably and easily come up with a > > fast fixer. A simple regexp should be cover 99% of all occurrences of > > u'' and u"". > > 2to3 already does this. > > My current thinking is that only b'' and u'' strings should be in 2.6 > code that you want to move to 3.0. Maybe -3 should warn about regular > string literals? That's a possibility. It might also help to have a 3to2 fixer that goes through a module and adds the needed prefixes so one doesn't have to go through manually to tack them on. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python source code on Bazaar vcs
On Thu, Mar 20, 2008 at 2:49 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Barry Warsaw schrieb: > > > I'm happy to announce that we now have available for public > > consumption, the Python source code for 2.5, 2.6 and 3.0 available > > under the Bazaar distributed version control system. > > Somebody has to fix the subversion related code in Python/sysmodule.c: > > [EMAIL PROTECTED]:~/dev/python/bzr/trunk$ ./python > Fatal Python error: subversion keywords missing > Aborted (core dumped) The ironic thing is that Barry is the one that added that code. =) -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for another build slave
> [Suggestion: perhaps we could set up a [EMAIL PROTECTED] > list for discussing buildbot administrative minutiae, rather than > polluting python-dev?] I think polluting python-dev is fine. Regards, Martin ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote: >I guess the only way to support all of these variants is >to use a filesystem based approach, e.g. by placing a file >with a special extension into some dir on sys.path. >The "database" logic could then scan sys.path for these >files, read the data and provide an interface to it. > >All bdist formats would then have to include these files. That's the idea behind the current version of PEP 262, yes, and I think it should be kept. >A separate FILES section also doesn't seem to be necessary - >we could just add one or more entries or the format: > >CreatesDir abc/ >CreatesFile abc/xyz1.py >CreatesDir abc/def/ >CreatesFile abc/def/xyz2.py >CreatesFile abc/def/xyz3.py >CreatesFile abc/def/xyz4.ini I actually think the size and hash information is good, in order to be able to tell if you're looking at an original file. I'm not sure how useful the permissions and uid/gid info is. I'm hoping we'll hear from anybody who has a use case for that. And of course, there are still some issues to be resolved regarding requirements, package name/version stuff, etc. But we can hash those out once we reach a quorum on the Distutils-SIG. ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
At 05:59 PM 3/21/2008 +0100, Christian Heimes wrote: >Phillip J. Eby schrieb: > > Questions, comments... volunteers? :) > >I've yet to read the monster package utils thread so I can't comment on >it. However I like to draw some attention to my PEP 370 >http://python.org/dev/peps/pep-0370/. It's about a site packages >directory in the users home directory. I think it quite related to the >discussion. Actually, it's 100% orthogonal, if done correctly. If anything, this slightly reduces the need for per-user site-packages, since in the new world, .pth files would generally only be needed for "develop" installs. (Assuming we find a way to support namespace packages without using .pth files, that is.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python source code on Bazaar vcs
On 21/03/2008, Brett Cannon <[EMAIL PROTECTED]> wrote: > Just to head this off, this is not a specific vote of confidence for > Bazaar. The Bazaar developers were at PyCon and both Barry and Thomas > were willing to put the time and effort to get the mirror up and going > while the Bazaar team was nearby to answer questions. At this point > this is more of an experiment to see if people like the development > style of distributed VCS. If people do and someone steps forward to > put the time and effort to add Mercurial support, we can then consider > doing something similar to what was done for the issue tracker. > > But for right now this is just to try out distributed VCS, nothing more. One thing I really like the idea of with Mercurial for my situation (non-committer) is the mq extension, which lets me manage my changes as a "stack of patches" - so I'm completely working with patches, which is what I have to post to the tracker, etc. Is there a similar workflow in Bazaar? I know there's the loom extension (although I haven't used it much yet) but I'm not sure how I'd use that. Basically, can some Bazaar expert offer a suggestion as to how a non-developer with read-only access would best use the Bazaar repositories to maintain a number of patches to be posted to the tracker? Thanks, Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: from __future__ import unicode_string_literals
> It's not implementable because the work has to occur in ast.c (see > Py_UnicodeFlag). It can't occur later, because you need to skip the > encoding being done in parsestr(). But the __future__ import can only > be interpreted after the AST is built, at which time the encoding has > already been applied. I think it would be possible to check for future statements on the basis of nodes already. Take a look at how Python 2.3 implemented future statements (why was that rewritten to use the AST, anyway?). > As for it not making sense, this is really in the realm of 2to3. I'm > beginning to really believe this statement in PEP 3000: There is still the original use case of people who don't want to run 2to3 (for whatever reasons - mostly probably subjective ones), and who would rather run a single code base unmodified. They don't care that documentation tells them this is impossible, when they feel they are so close to making it possible. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: from __future__ import unicode_string_literals
On 2008-03-21 22:32, Martin v. Löwis wrote: >> It's not implementable because the work has to occur in ast.c (see >> Py_UnicodeFlag). It can't occur later, because you need to skip the >> encoding being done in parsestr(). But the __future__ import can only >> be interpreted after the AST is built, at which time the encoding has >> already been applied. > > I think it would be possible to check for future statements on the > basis of nodes already. Take a look at how Python 2.3 implemented > future statements (why was that rewritten to use the AST, anyway?). > >> As for it not making sense, this is really in the realm of 2to3. I'm >> beginning to really believe this statement in PEP 3000: > > There is still the original use case of people who don't want to run > 2to3 (for whatever reasons - mostly probably subjective ones), and > who would rather run a single code base unmodified. They don't care > that documentation tells them this is impossible, when they feel they > are so close to making it possible. Could we point them to a special byte-code compiler such as Andrew Dalke's python4ply: http://dalkescientific.com/Python/python4ply.html That approach appears to be a lot easier to implement than trying to tweak the C implementation of the Python parser. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 21 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python source code on Mercurial
On 21/03/2008, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > I see your trunk history is stripped. For those who want the complete trunk > history (back to 17 years ago!), I have my own mirror here: > http://dev.pitrou.net:8000/cpython/trunk/ Excellent! For what it's worth, hg clone took 5 minutes on my PC (with broadband access). That's faster than simply downloading the Bazaar shared repository tarball (which took 13 minutes)! Are you keeping the mirror updated with respect to Subversion? I don't want to start a comparison at this point, but as neither system offers downloading of truncated history at the moment, the speed to grab a new clone of the full repository is likely to be pretty important. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?
> | try: > |bytes > | except NameError: > |bytes = str > | > | somewhere, then write the code as I proposed above. > > This is exactly the sort of thing that should be and I expect will be in > the conversion docs. That expectation might be unfounded (in the sense that it might not be written at all). I only happened to learn about that approach as I was converting Django to 3k. I'll happily put my experience in doing so into an email message, but I won't sit down and write a text document. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SVN FAQ for Windows users
> --- snippet --- > If you're using Windows make sure you have TortoiseSVN installed. > Right-click on the folder containing the trunk source code, expand the > TortoiseSVN submenu and select 'Apply Patch...'. Browse to the patch > file and select it, then right click on the file appearing in the > 'File Patches' window and click on 'Patch selected'. After you're > done, close the TortoiseMerge window. > --- /snippet --- That never worked for me. TortoiseSVN then insists on fetching the revisions mentioned in the patch, runs some math, and tells me that I can't apply the patch because it is out of date (assuming it really is, which is normally the case when I get to look at a patch). I then try cygwin patch, which applies the patch nicely, but messes up the line endings while doing so. So in the end, I conclude that it just isn't possible to apply patches on Windows, and log into a Linux machine to apply the patch. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SVN FAQ for Windows users
> Totally unrelated to your posting: > > I wonder why http://www.python.org/dev/faq/#how-to-make-a-patch uses tee > instead of > file ? So you can see what the patch looks like? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python source code on Mercurial
Hi, Paul Moore gmail.com> writes: > > Excellent! For what it's worth, hg clone took 5 minutes on my PC (with > broadband access). That's faster than simply downloading the Bazaar > shared repository tarball (which took 13 minutes)! > > Are you keeping the mirror updated with respect to Subversion? It is synchronized once an hour. cheers Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python source code on Bazaar vcs
On Fri, Mar 21, 2008 at 4:28 PM, Paul Moore <[EMAIL PROTECTED]> wrote: > On 21/03/2008, Brett Cannon <[EMAIL PROTECTED]> wrote: > > Just to head this off, this is not a specific vote of confidence for > > Bazaar. The Bazaar developers were at PyCon and both Barry and Thomas > > were willing to put the time and effort to get the mirror up and going > > while the Bazaar team was nearby to answer questions. At this point > > this is more of an experiment to see if people like the development > > style of distributed VCS. If people do and someone steps forward to > > put the time and effort to add Mercurial support, we can then consider > > doing something similar to what was done for the issue tracker. > > > > But for right now this is just to try out distributed VCS, nothing > more. > > One thing I really like the idea of with Mercurial for my situation > (non-committer) is the mq extension, which lets me manage my changes > as a "stack of patches" - so I'm completely working with patches, > which is what I have to post to the tracker, etc. > > Is there a similar workflow in Bazaar? I know there's the loom > extension (although I haven't used it much yet) but I'm not sure how > I'd use that. > bzr-loom is what you want. > > > Basically, can some Bazaar expert offer a suggestion as to how a > non-developer with read-only access would best use the Bazaar > repositories to maintain a number of patches to be posted to the > tracker? I tend to make a repository and make a working copy for each patch in it. The history is saved in the repository so it's efficient. > > > Thanks, > Paul. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SVN FAQ for Windows users
On 21/03/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: [...] > I then try cygwin patch, which applies the patch nicely, but messes > up the line endings while doing so. > > So in the end, I conclude that it just isn't possible to apply patches > on Windows, and log into a Linux machine to apply the patch. Generally, I use gnuwin32 patch (http://gnuwin32.sf.net), with the --binary flag. That seems to work most of the time for me. (The cygwin version may also have --binary). Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python source code on Bazaar vcs
On 21/03/2008, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > I tend to make a repository and make a working copy for each patch in it. > The history is saved in the repository so it's efficient. OK, so just lots of copies, fair enough. Presumably just use bzr diff to create patches? Much like Subversion, in practice, but with local commits of partial work. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python source code on Bazaar vcs
On Fri, Mar 21, 2008 at 5:04 PM, Paul Moore <[EMAIL PROTECTED]> wrote: > On 21/03/2008, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > > I tend to make a repository and make a working copy for each patch in > it. > > The history is saved in the repository so it's efficient. > > OK, so just lots of copies, fair enough. Presumably just use bzr diff > to create patches? Much like Subversion, in practice, but with local > commits of partial work. Yes, bzr diff should do the trick, although if you have local commits in it, you'll have to give the revision number manually. Bazaar also has this cool feature called merge directives. They let you bundle your branch (with all the commits) in a patch-like file, which can be easily merged into the mainline by core devs. Of course, Python hasn't moved to Bazaar, so widespread use of those is unlikely soon. > > > Paul. > Cheers, Benjamin Peterson ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
On 2008-03-21 22:21, Phillip J. Eby wrote: > At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote: >> I guess the only way to support all of these variants is >> to use a filesystem based approach, e.g. by placing a file >> with a special extension into some dir on sys.path. >> The "database" logic could then scan sys.path for these >> files, read the data and provide an interface to it. >> >> All bdist formats would then have to include these files. > > That's the idea behind the current version of PEP 262, yes, and I think > it should be kept. > >> A separate FILES section also doesn't seem to be necessary - >> we could just add one or more entries or the format: >> >> CreatesDir abc/ >> CreatesFile abc/xyz1.py >> CreatesDir abc/def/ >> CreatesFile abc/def/xyz2.py >> CreatesFile abc/def/xyz3.py >> CreatesFile abc/def/xyz4.ini > > I actually think the size and hash information is good, in order to be > able to tell if you're looking at an original file. I'm not sure how > useful the permissions and uid/gid info is. I'm hoping we'll hear from > anybody who has a use case for that. You're heading off in the wrong direction: we should not be trying to rewrite RPM or InnoSetup in Python. Anything more complicated should be left to tools which are specifically written to manage complex software setups. I honestly believe that most people would be happy if we just provide these two things (and no more): * install a package from a local archive, a URL or PyPI * uninstall a package in way that doesn't break other installed packages and whatever the mechanism, avoid making any undercover changes to the Python installation such as adding .pth files, overriding site.py, etc. - these are not needed if the tool keeps to the simple task of installing and uninstalling Python packages. Examples: python pypi.py install mypkg-1.0.tgz python pypi.py install http://www.example.com/mypkg-1.0.tgz python pypi.py install mypkg-1.0 python pypi.py uninstall mypkg If there's a dependency problem, the tool should print the list of other packages it needs. It should not try to install things automagically. If a package needs other modules as well, the package docs can point the user to use e.g. python pypi.py install mydep1-1.3 mydep2-2.3 mydep4-0.3 mypkg-1.0 instead. Anything more complicated should be left to specialized tools such as RPM, apt, MSI or the other such tools out there - after all the tool should be about Python *package* installation, not application installation. We *don't* need the tool to: * support multiple versions of a package (that's just bound to cause problems with pickle, isinstance() etc.) * provide namespace hacking (is a completely separate issue and can be handled by the packages rather than the install tool) * support all kinds of funky version numbers (if a package wants to participate in the system, the author better make sure that the version string fits the standard format) * provide some form of intra-package bus interface (ie. "entry points" as you call them) * provide support for keeping whole packages in ZIP files (doesn't play well with C extensions, clutters up the sys.path, is read-only, needs special importers, etc. etc. ) * try automatic version matching for required packages * download things from SourceForge or other sites with special download mechanisms * scan websites for links * make coffee, clean the house, send the kids to school :-) > And of course, there are still some issues to be resolved regarding > requirements, package name/version stuff, etc. But we can hash those > out once we reach a quorum on the Distutils-SIG. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 21 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3127 (Integer Literal Support and Syntax): %o and %b
On Tue, Mar 18, 2008 at 9:11 PM, Eric Smith <[EMAIL PROTECTED]> wrote: > I've been double checking the PEP 3127 implementation in py3k and the > backport I did to 2.6. The PEP says this about the % operator: > > "The string (and unicode in 2.6) % operator will have 'b' format > specifier added for binary, and the alternate syntax of the 'o' option > will need to be updated to add '0o' in front, instead of '0'." > > The %b operator was not added to 3.0, so I'll look into doing that in > both 2.6 and 3.0 (which I opened as issue 2416). > > What should be done for '%#o' formatting in 2.6? The above sentence > from the PEP implies it should be modified to add '0o' instead of '0', > even in 2.6. But that seems like a bad idea to me. Maybe it should > stay as-is, but add a -3 warning? Unfortunately, there'd be no way to > change your code to get rid of the warning, short of switching to > str.format() or adding a __future__ import (shudder). In 3.0, '%#o' > already adds the leading '0o'. I think this is such a tiny detail we shouldn't bother with a -3 warning. I agree that in 2.6, %#o should continue to do what it does in 2.5. Can you update the PEP? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Primer on distributed revision control?
With all these distributed revision control systems now available (bzr, hg, darcs, svk, many more), I find I need an introduction to the concepts and advantages of repository distribution. It seems to me that it has the potential for leading to anarchy, though I can see how some things would be improved (working offline, maintaining local patches). It's not obvious how I push changes back upstream. Can someone point me to some useful content (web pages or books) which will help me wrap my brain around the ideas? Maybe a compare/contrast of the major players? Thanks, Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)
zooko: > Um, isn't this tool called "unzip"? I have done this -- accessed the > source code -- many times, and unzip suffices. The type of issue I ran into with eggs is when you get an exception with a trace that includes an egg, you can't use the normal means to look at the code. Instead you have to understand that its an egg, unzip the code, manually translate the path, open the file and go to the line number. Similarly, you can't easily grep the code in its egg state. If there was a global flag where I could say 'install eggs as directories of source' then I'd be much happier. Just reread the EasyInstall documentation and '--always-unzip' is portrayed as a 'don't do this' option. As it is I just avoid eggs. They may make sense for installing applications but for development they get in the way. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Primer on distributed revision control?
On Fri, Mar 21, 2008 at 5:17 PM, <[EMAIL PROTECTED]> wrote: > With all these distributed revision control systems now available (bzr, > hg, > darcs, svk, many more), I find I need an introduction to the concepts and > advantages of repository distribution. It seems to me that it has the > potential for leading to anarchy, though I can see how some things would > be > improved (working offline, maintaining local patches). It's not obvious > how > I push changes back upstream. Can someone point me to some useful content > (web pages or books) which will help me wrap my brain around the ideas? > Maybe a compare/contrast of the major players? Unfortunately, Wikipedia's article doesn't seem up to snuff. http://www.dwheeler.com/essays/scm.html seems like a good overview of various players. http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf tells you why you should use it. I have found Bazaar's user guide to be a very gently gentle introduction to the topic: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html When you're ready for laughs, you can watch Linus give a talk on git: http://youtube.com/watch?v=4XpnKHJAok8 For anything else, Google it! > > > Thanks, > > Skip Cheers, Benjamin Peterson > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Primer on distributed revision control?
Eric Raymond started a study for this specific matter recently (announced here : http://article.gmane.org/gmane.emacs.devel/85893). Everything is under source control here : http://thyrsus.com/hg/uvc/ HTH, Quentin On Fri, Mar 21, 2008 at 11:17 PM, <[EMAIL PROTECTED]> wrote: > With all these distributed revision control systems now available (bzr, > hg, > darcs, svk, many more), I find I need an introduction to the concepts and > advantages of repository distribution. It seems to me that it has the > potential for leading to anarchy, though I can see how some things would > be > improved (working offline, maintaining local patches). It's not obvious > how > I push changes back upstream. Can someone point me to some useful content > (web pages or books) which will help me wrap my brain around the ideas? > Maybe a compare/contrast of the major players? > > Thanks, > > Skip > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/qgallet%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Primer on distributed revision control?
On Fri, Mar 21, 2008 at 05:17:00PM -0500, [EMAIL PROTECTED] wrote: > With all these distributed revision control systems now available (bzr, hg, > darcs, svk, many more), I find I need an introduction to the concepts and > advantages of repository distribution. It seems to me that it has the > potential for leading to anarchy, though I can see how some things would be > improved (working offline, maintaining local patches). It's not obvious how > I push changes back upstream. Can someone point me to some useful content > (web pages or books) which will help me wrap my brain around the ideas? http://en.wikipedia.org/wiki/Revision_control#Distributed_revision_control http://www.selenic.com/mercurial/wiki/index.cgi/UnderstandingMercurial http://www.selenic.com/mercurial/wiki/index.cgi/CommunicatingChanges http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#sharing-with-peers Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
On 21/03/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > You're heading off in the wrong direction: we should not be trying > to rewrite RPM or InnoSetup in Python. > > Anything more complicated should be left to tools which are > specifically written to manage complex software setups. > > I honestly believe that most people would be happy if we just > provide these two things (and no more): > > * install a package from a local archive, a URL or PyPI > > * uninstall a package in way that doesn't break other > installed packages > > and whatever the mechanism, avoid making any undercover > changes to the Python installation such as adding > .pth files, overriding site.py, etc. - these are > not needed if the tool keeps to the simple task of > installing and uninstalling Python packages. My immediate impression is that I completely agree with this. I'd like to add one capability - to be able to list all installed packages. Anything beyond this, I'd need to be persuaded about. That's not to say that it's not valuable, just that it should be separate from the installer. That's where setuptools falls down, in my view - it tries to do too much all in one package. > We *don't* need the tool to: [...] > * make coffee, clean the house, send the kids to school :-) Well, these would be useful :-) Paul. ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
At 11:13 PM 3/21/2008 +0100, M.-A. Lemburg wrote: >On 2008-03-21 22:21, Phillip J. Eby wrote: > > At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote: > >> I guess the only way to support all of these variants is > >> to use a filesystem based approach, e.g. by placing a file > >> with a special extension into some dir on sys.path. > >> The "database" logic could then scan sys.path for these > >> files, read the data and provide an interface to it. > >> > >> All bdist formats would then have to include these files. > > > > That's the idea behind the current version of PEP 262, yes, and I think > > it should be kept. > > > >> A separate FILES section also doesn't seem to be necessary - > >> we could just add one or more entries or the format: > >> > >> CreatesDir abc/ > >> CreatesFile abc/xyz1.py > >> CreatesDir abc/def/ > >> CreatesFile abc/def/xyz2.py > >> CreatesFile abc/def/xyz3.py > >> CreatesFile abc/def/xyz4.ini > > > > I actually think the size and hash information is good, in order to be > > able to tell if you're looking at an original file. I'm not sure how > > useful the permissions and uid/gid info is. I'm hoping we'll hear from > > anybody who has a use case for that. > >You're heading off in the wrong direction: we should not be trying >to rewrite RPM or InnoSetup in Python. I'm making the assumption that the author(s) of PEP 262 had good reason for including what they did, rather than assuming that we should start the entire process over from scratch. >Anything more complicated should be left to tools which are >specifically written to manage complex software setups. Tools which will need this data, in order to do their work. Hence, the reason for standardizing the data, instead of the tool(s). >[snip long list of features, both desired and undesired] Actually, *all* of these features are out of scope for stdlib development, because I'm not proposing including *any* tools for this in the stdlib, apart from distutils install and bdist_* support. I'm proposing, rather, that we finish the vision of PEP 262, of having a standard specification that *all* tools will abide by -- including rpm, dpkg, and what-have-you. Since *all* of these tools need to abide by that specification, their requirements will need to be considered in the formulation of the spec. And as I said, I'll be happy if all we do is get the distutils to abide by the spec for 2.6, even if it means we don't get an uninstall tool. That can always be installed later using Guido's bootstrap tool. :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Primer on distributed revision control?
On 21/03/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > With all these distributed revision control systems now available (bzr, hg, > darcs, svk, many more), I find I need an introduction to the concepts and > advantages of repository distribution. It seems to me that it has the > potential for leading to anarchy, though I can see how some things would be > improved (working offline, maintaining local patches). It's not obvious how > I push changes back upstream. Can someone point me to some useful content > (web pages or books) which will help me wrap my brain around the ideas? > Maybe a compare/contrast of the major players? The Mercurial book is good (http://hgbook.red-bean.com/) although it's Mercurial-specific (unsurprisingly). The Bazaar user guide (http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html) isn't bad, either, although I personally prefer the Mercurial book. I've yet to see a really good side-by-side comparison of Mercurial and Bazaar, which is a shame, as these 2 are to my mind, the hardest to differentiate in terms of features, etc. (Mercurial is generally considered faster, although Bazaar has caught up a lot recently. An up to date performance comparison would be interesting). Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SVN FAQ for Windows users
Martin v. Löwis schrieb: > That never worked for me. TortoiseSVN then insists on fetching the > revisions mentioned in the patch, runs some math, and tells me that > I can't apply the patch because it is out of date (assuming it really > is, which is normally the case when I get to look at a patch). Oh yeah, Tortoise tries to be "clever". Stupid turtle :( TortoiseSVN is great tool and IMHO the best GUI app for svn but its patching system it's more than annoying. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python source code on Bazaar vcs
On Fri, Mar 21, 2008 at 3:10 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > > > > > On Fri, Mar 21, 2008 at 5:04 PM, Paul Moore <[EMAIL PROTECTED]> wrote: > > > > On 21/03/2008, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > > > I tend to make a repository and make a working copy for each patch in > it. > > > The history is saved in the repository so it's efficient. > > > > OK, so just lots of copies, fair enough. Presumably just use bzr diff > > to create patches? Much like Subversion, in practice, but with local > > commits of partial work. > Yes, bzr diff should do the trick, although if you have local commits in it, > you'll have to give the revision number manually. That's not really true. Let's say you have a trunk branch that you keep which is pristine. You branch off of it and create a xxx branch. You can diff between xxx and trunk by running ``bzr diff xxx --old trunk``. You can also run this from within xxx with ``bzr diff --old ../trunk``. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python source code on Bazaar vcs
On Fri, Mar 21, 2008 at 6:12 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > On Fri, Mar 21, 2008 at 3:10 PM, Benjamin Peterson > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > On Fri, Mar 21, 2008 at 5:04 PM, Paul Moore <[EMAIL PROTECTED]> wrote: > > > > > > On 21/03/2008, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > > > > I tend to make a repository and make a working copy for each patch > in > > it. > > > > The history is saved in the repository so it's efficient. > > > > > > OK, so just lots of copies, fair enough. Presumably just use bzr diff > > > to create patches? Much like Subversion, in practice, but with local > > > commits of partial work. > > Yes, bzr diff should do the trick, although if you have local commits in > it, > > you'll have to give the revision number manually. > > That's not really true. Let's say you have a trunk branch that you > keep which is pristine. You branch off of it and create a xxx branch. > You can diff between xxx and trunk by running ``bzr diff xxx --old > trunk``. You can also run this from within xxx with ``bzr diff --old > ../trunk``. Well, I just learned something. ;) > > > -Brett > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python source code on Mercurial
On Fri, Mar 21, 2008 at 2:38 PM, Paul Moore <[EMAIL PROTECTED]> wrote: > On 21/03/2008, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > > I see your trunk history is stripped. For those who want the complete > trunk > > history (back to 17 years ago!), I have my own mirror here: > > http://dev.pitrou.net:8000/cpython/trunk/ > > Excellent! For what it's worth, hg clone took 5 minutes on my PC (with > broadband access). That's faster than simply downloading the Bazaar > shared repository tarball (which took 13 minutes)! > > Are you keeping the mirror updated with respect to Subversion? > > I don't want to start a comparison at this point, but as neither > system offers downloading of truncated history at the moment, Bazaar supports lightweight checkouts which act like svn checkouts. They are also actively working on allowing for partial checkouts. That way you can either specify an initial revision to pull the history down to or start with an initial lightweight checkout and have it save history as it pulls it over the network as you use it. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?
On Fri, Mar 21, 2008 at 2:40 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > | try: > > |bytes > > | except NameError: > > |bytes = str > > | > > | somewhere, then write the code as I proposed above. > > > > This is exactly the sort of thing that should be and I expect will be in > > the conversion docs. > > That expectation might be unfounded (in the sense that it might not be > written at all). I only happened to learn about that approach as I > was converting Django to 3k. > > I'll happily put my experience in doing so into an email message, > but I won't sit down and write a text document. Please do. I'll happily convert it into something more formal. Collin Winter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.6 and 3.0 tasks
Guido van Rossum schrieb: > Even though the more popular PyInt_ APIs are still available (even if > only as macros). THe PyInt_* macros are only available when Include/intobject.h is included explicitly. It's not in Python.h any more. > I disagree. Bad merges are already a frequent cause of instability in > 3.0. This could easily double the problems. And while I want to reduce > the instability (I really wish you would no commit until all unittests > pass), I also don't want the merges to cost more of your time! I'm trying my best but sometimes I don't spot the cause of a failing unit test. I got a slightly faster laptop so I'm now able to run the full unit test suite every time I do a svnmerge.py. > It doesn't have to be so black and white. Using the macro approach you > propose we can fix the situation at any time later. > > We could also make the changes in 2.6, so that the 2.6 code looks the > same as 3.0. (However for binary compatibility I think it would be > better if in 2.6 the linker sees PyString where in 3.0 it sees > PyBytes.) Let me get this straight. You propose that we replace PyString_ with PyBytes_ in both Python 2.6 and 3.0 core code. In Python 2.6 some macros replace the PyBytes_* functions with PyString_ so the linker sees PyString_*? Mmh, it sounds like an interesting idea :] Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python source code on Bazaar vcs
On Sat, Mar 22, 2008 at 8:28 AM, Paul Moore <[EMAIL PROTECTED]> wrote: > Basically, can some Bazaar expert offer a suggestion as to how a > non-developer with read-only access would best use the Bazaar > repositories to maintain a number of patches to be posted to the > tracker? > Here's what I'd do: get Python, make a branch for my patch, hack on the patch in the branch, then use merge --preview to generate a diff. If you want to maintain a long-lived branch of Python with patches, say you're maintaining a distro package, then looms are your best bet. For those inclined to specifics, here's a near-exact example of what I would do: # Get Python bzr init-repo ~/src/python cd ~/src/python bzr branch # Make a patch bzr branch trunk docstring-fix-bug-123456 cd docstring-fix-bug-123456 bzr ci -m 'Correct some spelling' bzr ci -m 'Oops. Make sure we use US English' # Move the unrelated work to another branch. cd .. bzr branch trunk testcase-add-cleanup cd testcase-add-cleanup bzr merge --uncommitted ../docstring-fix-bug-123456 bzr ci -m "Add addCleanup method to TestCase. Schedules a nullary callable to be run before tearDown" # Prepare the patches cd ../trunk bzr merge --preview ../docstring-fix-bug-123456 > ~/Desktop/docstring.patch bzr merge --preview ../testcase-add-cleanup > ~/Desktop/add-cleanup.patch Hope this helps, jml ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.6 and 3.0 tasks
On Fri, Mar 21, 2008 at 4:41 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Guido van Rossum schrieb: > > > Even though the more popular PyInt_ APIs are still available (even if > > only as macros). > > THe PyInt_* macros are only available when Include/intobject.h is > included explicitly. It's not in Python.h any more. > > > > I disagree. Bad merges are already a frequent cause of instability in > > 3.0. This could easily double the problems. And while I want to reduce > > the instability (I really wish you would no commit until all unittests > > pass), I also don't want the merges to cost more of your time! > > I'm trying my best but sometimes I don't spot the cause of a failing > unit test. I got a slightly faster laptop so I'm now able to run the > full unit test suite every time I do a svnmerge.py. :-) > > It doesn't have to be so black and white. Using the macro approach you > > propose we can fix the situation at any time later. > > > > We could also make the changes in 2.6, so that the 2.6 code looks the > > same as 3.0. (However for binary compatibility I think it would be > > better if in 2.6 the linker sees PyString where in 3.0 it sees > > PyBytes.) > > Let me get this straight. You propose that we replace PyString_ with > PyBytes_ in both Python 2.6 and 3.0 core code. In Python 2.6 some macros > replace the PyBytes_* functions with PyString_ so the linker sees > PyString_*? Mmh, it sounds like an interesting idea :] Right. We've done this 2-stage rename before, during the great (sometimes known as grand) renaming, in the 1.x days. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trove classifiers
On Thu, Mar 20, 2008 at 9:43 AM, Fred Drake <[EMAIL PROTECTED]> wrote: > On Mar 20, 2008, at 11:55 AM, Oleg Broytmann wrote: > > Yes, exactly. Eric Raymond claims to be the inventor, but there are > > different voices against him: > > http://damagestudios.net/blog/2005/08/15/sourceforge-founders > > > That contests that Raymond was an "architectural granddaddy of > SourceForge", not that he invented Trove. My understanding is that he > did start the efforts to define the Trove classifiers as part of a > larger effort that never panned out, but that defining the classifiers > was not a solo effort. That's my recollection too. And yes, Eric would like to have invented open source. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
> I'm making the assumption that the author(s) of PEP 262 had good > reason for including what they did, rather than assuming that we > should start the entire process over from scratch. The objections to the PEP remain the same as they were then, though: In the requirements, it says "we need", without saying why we need. It then goes on saying "we want" (rephrased) "to duplicate APT and RPM", without saying why we want that, or why that brings us closer to what we need. IOW, the PEP is lacking a rationale. >> Anything more complicated should be left to tools which are >> specifically written to manage complex software setups. > > Tools which will need this data, in order to do their work. Hence, > the reason for standardizing the data, instead of the tool(s). If there was a chance that the infrastructure being developed actually helps these tools, *that* would be a reasonable goal, IMO. However, I'm extremely skeptical that this can ever succeed to the degree that whoever provides RPMs, .debs, or MSI files will actually use such data, as they will find that the data are incomplete, and they have to redo all of it, anyway. > I'm proposing, rather, that we finish the vision of PEP 262, of > having a standard specification that *all* tools will abide by -- > including rpm, dpkg, and what-have-you. Do you also envision the objective of PEP 262, then? I.e. to provide a database of installed packages, in .../install-db? > And as I said, I'll be happy if all we do is get the distutils to > abide by the spec for 2.6, even if it means we don't get an uninstall > tool. That can always be installed later using Guido's bootstrap tool. :) I'm even more skeptical here. If the assumption is that the package database allows for uninstallation, I'm -1. IOW, RPM, deb, MSI should then *not* write to that package database, as they also write to a different database, out of the scope of the PEP, and this is what uninstallation should use. Regards, Martin ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
On Fri, Mar 21, 2008 at 06:41:00PM -0400, Phillip J. Eby wrote: > I'm making the assumption that the author(s) of PEP 262 had good > reason for including what they did, rather than assuming that we > should start the entire process over from scratch. The goal *was* originally to provide for RPM-like verification of file content, but I don't know that the verification feature really matters that much; OSes with packaging systems already support such a feature, probably, and it probably isn't particularly useful for systems without a packaging system. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
I'm following up on this thread without checking if there were other following negating a need to respond... If so, ignore as needed. +1 from me. Always build on windows into an architecture specific PCBuild/XXX directory. A bonus if the directory name matches the return value of platform.machine() but I don't care too much about that part. (that'd mean 'i686' and 'x86_64' and who knows what for Itanic users) On Wed, Jan 30, 2008 at 11:25 PM, Mark Hammond <[EMAIL PROTECTED]> wrote: > I'm wondering if anyone has any comment on this issue? Its currently > impossible to use distutils as documented to build x64 extensions, either > natively or cross-compiled using the trunk and while I'm keen to help fix > this, I'd like agreement on the direction. > > Can I assume silence means general agreement on the compromise proposal I > outlined? > > Thanks, > > Mark > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Mark Hammond > > Sent: Tuesday, 22 January 2008 9:06 PM > > To: '"Martin v. Löwis"' > > Cc: [EMAIL PROTECTED]; [email protected] > > Subject: Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows > > > > Hi Martin, > > > > Way back on Monday, 21 May 2007, you wrote: > > > > > This is an issue to be discussed for Python 2.6. I'm personally > > > hesitant to have the "official" build infrastructure deviate > > > from the layout that has been in-use for so many years, as a lot > > > of things depend on it. > > > > > > I don't find the need to have separate object directories convincing: > > > For building the Win32/Win64 binaries, I have separate checkouts > > > *anyway*, since all the add-on libraries would have to support > > > multi-arch builds, but I think they don't. > > ... > > > > * Re the x64 directory used by the PCBuild8 process. IMO, it makes > > > > sense to generate x64 binaries to their own directory - my > > expectation > > > > is that cross-compiling between platforms is a reasonable use-case, > > > > and we should support multiple achitectures for the same compiler > > > > version. > > > > > > See above; I disagree. > > > > [For additional context; the question was regarding where the output > > binaries were created for each platform, and specifically if x64 build > > should use something like 'PCBuild/x64'] > > > > I'm bringing this topic up again as I noticed the AMD64 builds for > > Python > > 2.6 create their output in the PCBuild/x64 directory, not directly into > > the > > PCBuild directory. When I raised this with Christian, he also > > expressed a > > desire to be able to cross-compile in the same directory structure and > > was > > unaware of this discussion (but I made him aware of it :) > > > > You made excellent points about how tools currently recognize the > > PCBuild > > directory, and we can't break them, and I agree. I'd like to propose a > > compromise that might be able to keep everyone happy. > > > > The main problem I see with all platforms using 'PCBuild' is that in a > > cross-compilation scenario, it is impossible for the distutils to > > determine > > the location of the correct Python libraries to link with (stuff in its > > own > > PYTHONHOME is no good; it's for the wrong platform). Obviously, we can > > change the distutils so that the location of the correct libraries can > > be > > specified, but that implies all other build systems that currently > > assume > > PCBuild must also change to work in a cross-compilation scenario. > > While > > those external tools *will* work today in a native build on x64, > > eventually > > they may need to be upgraded to deal with cross-compilation - and this > > means > > that all such tools will also be unable to automatically determine the > > location of the libraries. They will all need to take the library dir > > as a > > user-specified option, which seems a pain (eg, buildbots would seem to > > need > > site-specific configuration information to make this work). If > > eventually > > all such tools are likely to upgrade, it would be ideal if we can offer > > them > > a way to upgrade so the correct libraries can be determined > > automatically, > > as they can now for native builds. > > > > My compromise proposal is this: Each platform builds in its own > > directory > > (ie, PCBuild/x86_64, PCBuild/x86). Every single build configuration > > has a > > post-build step that copies the result of the build to the PCBuild > > directory. We then add an option to the distutils so that a cross- > > compile > > platform can be specified and when it is, to use 'PCBuild/{platform}" > > instead of PCBuild, and we encourage other tools to use the same > > directory > > should they want to support "configure-less" cross-compilation (if > > distutils > > on the trunk is not still trying to maintain b/w compat, it should just > > *always* look in PCBuild/{platform}, and I'd suggest py3k not bother > > with > > PCBuild at all; build systems will be touched t
Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond
At 02:31 AM 3/22/2008 +0100, Martin v. Löwis wrote: >>I'm making the assumption that the author(s) of PEP 262 had good >>reason for including what they did, rather than assuming that we >>should start the entire process over from scratch. > >The objections to the PEP remain the same as they were then, >though: In the requirements, it says "we need", without saying >why we need. It then goes on saying "we want" (rephrased) >"to duplicate APT and RPM", without saying why we want that, >or why that brings us closer to what we need. > >IOW, the PEP is lacking a rationale. Ok, well, I have a rationale for it: make it possible to get rid of eggs as a mechanism for supporting easy_install. Many people (yourself included) have criticized eggs as an installation mechanism, and this is an alternative that gets rid of .egg files and directories in that case, and most of the need for .pth file usage as well. >If there was a chance that the infrastructure being developed >actually helps these tools, *that* would be a reasonable goal, >IMO. Yes, I'm of course primarily interested in Python-specific tools such as virtualenv, easy_install, buildout, and the as-yet-unwritten uninstallers, package listers, etc., that can usefully read or write such data. >However, I'm extremely skeptical that this can ever succeed >to the degree that whoever provides RPMs, .debs, or MSI >files will actually use such data, as they will find that >the data are incomplete, and they have to redo all of it, >anyway. The data isn't for them to use to meet their use cases, it's for them to *provide* so that Python tools don't stomp on, uninstall, or otherwise interfere with files installed by the system. In other words, for system packagers, it's a communication from the system to Python, rather than the other way around. Even though the distutils will build the file in the bdist, the system packaging tools would be free to generate their own file listing and signatures and such. >Do you also envision the objective of PEP 262, then? I.e. >to provide a database of installed packages, in .../install-db? In each directory relative to a given sys.path directory, yes. That is, installing a distutils distribution to any directory would result in a file being added to an install-db within that directory. (Assuming we use the proposed implementation model of PEP 262, which at the moment I don't see any substantial obstacle to.) >>And as I said, I'll be happy if all we do is get the distutils to >>abide by the spec for 2.6, even if it means we don't get an >>uninstall tool. That can always be installed later using Guido's >>bootstrap tool. :) > >I'm even more skeptical here. If the assumption is that the package >database allows for uninstallation, I'm -1. IOW, RPM, deb, MSI >should then *not* write to that package database, as they also write >to a different database, out of the scope of the PEP, and this is >what uninstallation should use. I probably should have brought this up, in fact, I think I mentioned it in a previous thread, but I would like to see PEP 262 add a way to say "this is a system-installed package, *don't touch*". The idea again is not to do the job of the native packaging system, but rather to ensure that Python-specific tools (e.g. easy_install and friends) do not interfere or conflict with it. A big problem in the early development of easy_install, even using eggs, was that there was no way to tell whether it was safe to delete or overwrite an existing file or directory that was already installed on the system. A mechanism like this would allow tools like easy_install to say, "oh, your system packager has a conflicting package here, you need to use that tool to sort this out if you really want to do something here. I'm not going to touch that." Without something like this, there is no way to tell the difference on many systems between a system package and something the user has put there with "sudo python setup.py install". ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
At 09:44 PM 3/21/2008 -0400, A.M. Kuchling wrote: >On Fri, Mar 21, 2008 at 06:41:00PM -0400, Phillip J. Eby wrote: > > I'm making the assumption that the author(s) of PEP 262 had good > > reason for including what they did, rather than assuming that we > > should start the entire process over from scratch. > >The goal *was* originally to provide for RPM-like verification of file >content, but I don't know that the verification feature really matters >that much; OSes with packaging systems already support such a feature, >probably, and it probably isn't particularly useful for systems >without a packaging system. Actually, it's the places where there's no packaging system that it's most useful. For example, an application that installs plugins to itself. A development environment with multiple virtual pythons. Users installing stuff to their PYTHONPATH, etc. In these cases, having the Python-specific tools be able to verify content signatures is useful, to make sure that you know what you're updating or removing. This is particularly important if one installs anything just by unpacking it into the target directory; you could overwrite something and then have only size/signature info to sort out whose version of the file is actually there. I more question the permissions and uid/gid stuff; I'm not really clear on what I'd use that stuff for in easy_install/uninstall/etc. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] httplib &c. timeouts and global state
http://python.org/sf/2451 """ The new timeout support in 2.6 makes use of new function socket.create_connection(). socket.create_connection() provides no way to disable timeouts, other than by relying on socket.getdefaulttimeout() returning None. This is unfortunate, because it was the purpose of the new timeout support to allow control of timeouts without reliance on global state. setdefaultsocket.create_connection() should always call sock.settimeout() with the timeout passed to create_connection(), unless a special non-None value is passed indicating that the global default is to be used. Specific modules may then use that special non-None value where required, to preserve backwards-compatibility. """ Facundo doesn't seem to agree. If I understand him correctly, he objects to the use of a special value other than None as an argument value. I think avoiding this minor complication is secondary to avoiding gratuitously imposing global state on users where it's not needed. Much existing code uses .setdefaulttimeout(), because legacy code does not expose the socket timeout. Of course, not all of that code can be changed immediately (otherwise, why did we wait so long before Facundo did his valuable work on this?). Of course, very often, code that calls socket.setdefaulttimeout(some_non_none_value) wants a default timeout for everything. But that isn't *always* the case, and standard library modules that expose the timeout feature should not make that assumption. For example, an application might only want to set a timeout for some non-essential network operation. As another example, useful but poorly-written library code might call .setdefaulttimeout(). Also, ISTM there's a big difference between nobody having contributed the time to implement the feature on the one hand, and deliberately imposing the global socket timeout state on users on the other! Facundo indicates in the tracker discussion for 2451 that a decision was made here about this, but doesn't recall exactly which post, and directed me here. What I found in the archive is this thread (sorry for the non-python.org URL): http://www.gossamer-threads.com/lists/python/dev/555039?do=post_view_threaded#555039 In that discussion, this issue is raised, but I don't see any resolution that answers the objection made in issue 2451. Anyway, apologies in advance if there was a decision here that takes account of the above objection. I do want to thank Facundo for adding the timeout support to modules such as httplib. But I also want to loudly complain about this detail :-) John ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Primer on distributed revision control?
[EMAIL PROTECTED] writes: > With all these distributed revision control systems now available (bzr, hg, > darcs, svk, many more), I find I need an introduction to the concepts and > advantages of repository distribution. > Can someone point me to some useful content (web pages or books) > which will help me wrap my brain around the ideas? Maybe a > compare/contrast of the major players? Others have mentioned a bunch of resources. They're all OK, and should reassure you that dVCS is not all that different from what you're used to. Here I'll post some comments that as far as I know are not in any of the existing resources. One caveat that you should be very careful about while reading them: any command that involves receiving changes from a remote repo and updating your workspace. Terms like "get", "fetch", "pull", "update", "clone", and even "checkout" are commonly used to describe these operations, but the actual semantics of the commands named by those terms differs wildly. For example, in git, "fetch" receives the metadata and new content, while "pull" does a fetch, then attempts to update the workspace and performs 3-way merges. In Mercurial, "pull" and "fetch" have the opposite semantics. Also, note that while CVS and Subversion automatically do a merge when updating, the dVCSes all make this distinction between fetching new content and merging it into your workspace. As already described, some of them normally combine the operations, others tend to ask the user to do them "by hand", but all provide both ways to do it. (That should send a shiver down your Pythonic spine!) Another one is that in git and Mercurial, "clone" replicates a repo, while "checkout" switches between branches in a single workspace. In bzr, "clone" is an alias for "checkout", and normally creates a new workspace. > It's not obvious how I push changes back upstream. It is very important to remember that in centralized systems like CVS or Subversion, committing *is* pushing, while in a dVCS these operations are separate. In many projects the workflow is that you *record* your changes in a local repo, then you *push* them to a shared repo. AFAIK all of the contenders do call the record operation "commit", and the publish operation "push".[1] (Other workflows you will hear about are based on mailing patches -- eg, Linux, while yet others are based on gatekeepers pulling from your repo -- Arch developers tend to favor this. Don't worry about them, these are not going to be relevant to Python for a while.) >From a participating developer's point of view, Eric Raymond's in-progress survey captures this aspect pretty well as a distinction between "update before record" and "merge after record" (my terms, not his). The point is that in CVS or Subversion, you *cannot* commit to mainline if you haven't merged in all concurrent changes to mainline. In a distributed VCS, on the other hand, you record your changes locally at will, then merge revisions at your convenience, finally pushing them upstream. It sound like a small difference, but it's actually amazingly liberating. Otherwise, it doesn't need to be any different from your current workflow, and I doubt that it will be until the most active Python developers start to feel a need for it. > It seems to me that it has the potential for leading to anarchy, git is *designed* around Linus's ability to manage chaos, but because of Linus, there is no anarchy. The same will be true for Python (although the personalities of the leading developers are different, so the details of why no anarchy will differ). A more optimistic way to put your point is that dVCSes have a great potential for encouraging experimentation. In general, you'll always have a pretty good idea where you want to pull from, and the gatekeepers will tell if you may and where to push. Footnotes: [1] Darcs uses "record" for the record operation, but Darcs is highly unlikely to become the Python dVCS of choice. ___ Python-Dev mailing list [email protected] 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 we can get rid of eggs for 2.6 and beyond
Phillip J. Eby wrote: > At 11:21 AM 3/21/2008 -0500, [EMAIL PROTECTED] wrote: >> Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the >> Joachim> files (and 'rmdir' directories, but not recursively) that it >> Joachim> created, and that have not been modified in the meantime (after >> Joachim> the installation). >> >> That's not sufficient. Suppose file C (e.g. /usr/local/etc/mime.types) is >> in both packages A and B. >> >> Install A - this will create C >> Install B - this might overwrite C, saving a copy, or it might retain >> A's copy. >> Uninstall B - this has to know that C is used by A and not touch it > > Correct. However, in practice, B should not touch C, unless the file > is shared between them. > > This is a key issue for support of namespace packages, at least if we > want to avoid using .pth files. (Which is what setuptools-built > system packages do for namespace packages currently.) > > Of course, one possible solution is for both A and B to depend on a > "virtual package" that contains C, such that both A and B can install > it if it's not there, and list it in their dependencies. But this is > one of the handful of open issues that needs to be resolved with Real > Life Package Management people, such as Debian, Fedora, etc. I've always thought that the right way to handle the dependency DAG is to treat it as a garbage collection problem. Assume that for each package there is a way to derive the following two pieces of information: (a) whether this package was installed explicitly by the user, or implicitly as the result of a dependency, and (b) the set of dependencies for this package. Then, starting with the list of 'explicit' packages as the root set, do a standard mark & sweep; Any package not marked is a candidate for removal. -- Talin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
