Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Ronald Oussoren]

On 22 Mar, 2008, at 2:44, 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.


Why not? Checksums would allow you to build a small packaging system
on top the python system.

Ronald

smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python source code on Bazaar vcs

[Georg Brandl]

Matthieu Brucher schrieb:

> 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.

> 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.

In any case, the reason for using a VCS should never be the market share,
but its advantages for development, e.g. speed, usability, community
support.

cheers,
Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python source code on Mercurial

[Georg Brandl]

Antoine Pitrou schrieb:
> 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 :-))

Thanks, nice work! That is certain to make my Python contributions a bit
better organized...

cheers,
Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Neal Becker]

Another use case, which I find in my world, is that there are always
packages that interest me (found at pypi), that my vendor hasn't packaged
as rpms yet.

With finite resources, this will always be true.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Steve Holden]

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.
> 
> Anything more complicated should be left to tools which are
> specifically written to manage complex software setups.
> 
We *do* need a way to play nice with all the various platform 
installers. This would surely be welcomed by the many third parties who 
now have to package Python for their platforms.

> 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.
> 
... unless explicitly asked to do so? It seems silly to omit this 
capability when it's essentially just omitting a recursive call.

> 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.
> 
Why would this be better than using --load-dependencies?

> 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.)
> 
Another argument for installing apps as separate components with all 
dependencies. I really don't believe enough consideration has been given 
as to the essential difference between these two activities.

>   * 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)
> 
Agreed.

>   * 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. )
> 
It shouldn't require special importers, though. And if the zip file 
contains compiled code the read-only nature doesn't matter if the zips 
are version-specific.

>   * 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 :-)
> 
But a package that *would* do this could be immensely popular.

>> 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.
> 
Well, I've probably been killfiled into non-existence on this list by 
now, but it seems to me that we are in danger of answering the wrong 
problem yet again. But that's all I have to say on this topic, so you 
can all heave a sigh a relief and get on with messing it up ;-)

re

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Martin v. Löwis]

> 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.

How so? I cannot see the need for .egg files or .pth files in the
first place. If they exist so that you can import stuff: just install
to site-packages, and be done.

> 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.

Ok, that's a reasonable requirement. It will be difficult to implement,
though, as it will require Linux distributors (in particular) to include
the database snippets in their packages.

Essentially, one would have to contribute patches to all the 
distributions (we care about, at least), and then nag the respective
maintainers to include these patches.

> 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.

Something like a read-only flag?

For those without the read-only flag, the specification should
explicitly say what manipulation is allowed.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Proposal: Slightly Changed Semantics for from-Import

[Armin Ronacher]

Hi all,


I propose a small change on the "from"-import behavior.  Currently there are two
ways to import a module name foo from bar.  Namely "import foo.bar as bar" and
"from foo import bar".  The main problem with the second is that it will not
work in every situation.

Modules are registered with their names in sys.modules before the import but
become and attribute of their parent after.  This leads to the surprising
behavior that "from foo.bar import baz" works but "from foo import bar" not
until the foo.bar module finished setting up.

This behavior is especially surprising if you have circular dependencies and you
notice that your imports work properly if you import a specific module before
another one and will fail if you import it afterwards although it doesn't seem
like that should make any difference.

My proposal is that "from foo import bar" returns sys.modules["foo.bar"] if this
one exists and the foo.bar attribute lookup failed.

If a test case is needed I can attach one later on.


Regards,
Armin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Testing documentation snippets

[Georg Brandl]

Hi,

the newest version of Sphinx supports testing doctest (and other) snippets
in the documentation.  Since we have many examples in the docs that may
get out of date, I think this is a valuable thing to have.

I've started making the doctests runnable with Sphinx in three documents;
the functional howto, the RE and the Decimal docs.

If you want to know how to run the doctests, it should be as easy as

$ cd Doc
$ make doctest PYTHON=../python

on UNIX. The PYTHON=../python is needed to really test against the tree
version of Python, not the system-wide installed one.

If you want to run only tests in one source file, run

$ make doctest PYTHON=../python SOURCES=library/decimal.rst

If there is further interest in this, I'll explain the details how to
"activate" examples to work with "make doctest".

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python source code on Mercurial

[Paul Moore]

On 21/03/2008, Brett Cannon <[EMAIL PROTECTED]> wrote:
> 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.

I know, but the details aren't 100% clear yet. Mercurial is in much
the same situation (although perhaps less far down that route - Bazaar
development seems far faster at the moment, for better or worse).

One point, which I assume you know but others may not  - a bazaar
"checkout" is not like a local branch. In a checkout, all commits go
straight back to the parent branch, meaning that local commits aren't
possible (OK, that's an oversimplification, but let's keep things
simple) and the workflow is much more like Subversion.

The biggest problem with DVCSs is the vast range of subtly different
terminology, for related but distinct concepts. It makes having a
common terminology for comparisons really hard, resulting in all sorts
of confusion :-(

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python source code on Mercurial

[Benjamin Peterson]

On Sat, Mar 22, 2008 at 7:39 AM, Paul Moore <[EMAIL PROTECTED]> wrote:

> On 21/03/2008, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > 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.
>
> I know, but the details aren't 100% clear yet. Mercurial is in much
> the same situation (although perhaps less far down that route - Bazaar
> development seems far faster at the moment, for better or worse).
>
> One point, which I assume you know but others may not  - a bazaar
> "checkout" is not like a local branch. In a checkout, all commits go
> straight back to the parent branch, meaning that local commits aren't
> possible (OK, that's an oversimplification, but let's keep things
> simple) and the workflow is much more like Subversion.

You can commit locally on a Bazaar checkout by adding the --local option to
commit. This feature is supposed to add the flexibility to have team
branches, where a bunch of people can work on a branch.

>
>
> The biggest problem with DVCSs is the vast range of subtly different
> terminology, for related but distinct concepts. It makes having a
> common terminology for comparisons really hard, resulting in all sorts
> of confusion :-(
>
> Paul.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Paul Moore]

On 22/03/2008, Steve Holden <[EMAIL PROTECTED]> wrote:
> Well, I've probably been killfiled into non-existence on this list by
>  now, but it seems to me that we are in danger of answering the wrong
>  problem yet again. But that's all I have to say on this topic, so you
>  can all heave a sigh a relief and get on with messing it up ;-)

You probably have my company in the killfile, but I have a nagging
feeling in the same direction. My biggest problem is that I can't
express what I believe is the *right* problem, beyond the over-general
statement that it seems crucial to me that there should be a single,
unified way of managing *all* packages installed in a given Python
installation. Whether that's a Python-only solution, or the system
packager, doesn't matter. There should be only one way to do it, to
reuse a well-known phrase :-)

If you know how to state nature of the right problem, that would be useful.

All this talk of "playing nicely with the system packager" seems to
imply that people are designing a second solution, and trying to
manage the interaction, rather than deciding on *one* solution (which
by definition has no interaction to worry about).

It's reasonable to have multiple solutions for multiple Python
installations (system packager for the system python, python packager
for a local install, for example) but that's a different matter.

Oh, and application installation is (should be) completely different.
On Windows, applications should probably be bundled with their own
Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
standard is, so I'd have to defer to others.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Martin v. Löwis]

> It seems to me that this discussion is being undermined by not
> acknowledging the many use cases up front. There is no rationale
> because there are too many tacit rationales.

I honestly, really, cannot imagine what those are. Explicit is
better than implicit.

> Nevertheless, the many
> use cases are related at some level and would benefit from some form
> of lowest-common-denominator support in the standard library. As an
> example, IF I wanted to use a library to support multi-version
> packages or one to ensure I had all the dependencies, I would need to
> know what versions of things were currently installed.

How would you install multiple versions in the first place? Python
supports no such thing, at least not without setting PYTHONPATH,
or otherwise changing sys.path.

> My personal use case is for multi-version packages. I deploy many
> small scripts (not applications) that use an evolving set of base
> libraries. I don't want the older scripts to hold me back from pushing
> forward with the base libraries, so I peg the scripts to their
> respective major versions as I release them.

I could not have imagined that as a use case. I never install multiple
versions of the same thing on the same system, except for Python itself.
I also try to avoid using evolving libraries as much as possible,
and quickly abandon libraries if they change in an incompatible manner
across releases, at least if porting becomes too much of a burden.

Notice that this use case isn't listed in the PEP, and I cannot see
how the PEP can help providing that functionality.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Paul Moore]

On 22/03/2008, Alexander Michael <[EMAIL PROTECTED]> wrote:
>  >  IOW, the PEP is lacking a rationale.
>
> It seems to me that this discussion is being undermined by not
>  acknowledging the many use cases up front. There is no rationale
>  because there are too many tacit rationales.

Absolutely! It feels like people are trying to design a solution
without having written up the problem spec. Maybe that's because there
are too many problems for a single solution to work in all cases?

>  My personal use case is for multi-version packages. I deploy many
>  small scripts (not applications) that use an evolving set of base
>  libraries. I don't want the older scripts to hold me back from pushing
>  forward with the base libraries, so I peg the scripts to their
>  respective major versions as I release them.

My personal use case is for a Windows system with a number of adhoc
scripts, which may depend on 3rd party libraries, and a number of
"applications" (3rd party or otherwise) written in Python.

I want the applications to use a bundled Python and library, via
py2exe. There should be no dependency on the "system" Python.

Adhoc scripts can depend on libraries installed into the system
Python, but generally there will be a "base" set of libraries that I
will always have installed and which can be assumed to be present
(pywin32, cx_Oracle, py2exe, ...). Scripts can use these without
restriction but should be prepared to work with whatever version is
present. It should (almost) never be a problem to a script if a
library gets upgraded.

Additional libraries may be installed in the system Python, for
one-off jobs, or for testing and development. I will install and
remove these at will, and nothing critical should break ifn I do.

There is generally no other Python present on the system. On my
development machine, I may have alternative versions installed, and I
may have trunk checkouts with a python.exe built, but these will never
be used for anything other than specific development tasks, and are
treated as "throw-away". It's very rare that any 3rd party library
will be installed in these, and special handling when it does happen
is entirely acceptable.

For the system Python, I need:
- a single way to list what's installed (including version)
- a single way to uninstall items as needed
- a way (or more than one) to install 3rd party software *which ties
into the above*

The key maintenance task I do on the system Python is to list
everything installed, uninstall them all, upgrade the system Python,
then reinstall the ones I had installed previously. (Don't bother
telling me there are other ways I could do this - that's not the point
here, this is how I actually work).

The reason setuptools/easy_install breaks this is because it fails the
"single way" test. I have to use bdist_wininst for some packages, so
setuptools *has* to integrate with that. Also, setuptools doesn't have
the list and uninstall features.

So that's my problem/requirements. Anything that solves this gets +1
from me. Anything else gets -1 or at best -0. Anything that adds extra
features while not solving my problem gets a strong -1, as the extra
features will encourage take-up of that solution, exacerbating my
current problem.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Martin v. Löwis]

>> Essentially, one would have to contribute patches to all the 
>> distributions (we care about, at least), and then nag the respective
>> maintainers to include these patches.
> 
> Not true.  You just need to make sure that "setup.py install" creates
> that database.  With the proposed format of the database this is just
> a file in the correct location - exactly for this reason.  Next time
> the distribution will build the package that database file will be in
> place.

How so? Are you /sure/ the packaging process even *runs* setup.py?
And if they do, why do you think they will pick up the database
file?

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Paul Moore]

On 22/03/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> How would you install multiple versions in the first place? Python
>  supports no such thing, at least not without setting PYTHONPATH,
>  or otherwise changing sys.path.

That's an unrelated feature of setuptools, providing a way to
"install" multiple versions of a package and select which version you
want at runtime. It does this by sys.path manipulation, I believe.

It's a good example of the sort of orthogonal feature which makes
setuptools such an issue. It's a genuinely useful feature to some
people, but it's unrelated to packaging and installation, so people
buy into a packaging solution (eggs) for the non-packaging benefits
they provide.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python source code on Mercurial

[Paul Moore]

On 22/03/2008, Benjamin Peterson <[EMAIL PROTECTED]> wrote:
> > One point, which I assume you know but others may not  - a bazaar
> > "checkout" is not like a local branch. In a checkout, all commits go
> > straight back to the parent branch, meaning that local commits aren't
> > possible (OK, that's an oversimplification, but let's keep things
> > simple) and the workflow is much more like Subversion.
> You can commit locally on a Bazaar checkout by adding the --local option to
> commit. This feature is supposed to add the flexibility to have team
> branches, where a bunch of people can work on a branch.

Sigh. I said I know it's a simplification. IIRC, you can't manage a
mixture of local and remote commits. You have to push your local
commits before doing a remote commit.

But that's more detail than is needed at the moment. Please can we
keep things at a high level for the people who haven't experimented
with DVCS tools yet. (I know, I'm as much to blame as anyone. I'm
going to stop now).

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Neal Becker]

"Martin v. Löwis" wrote:

>>> Essentially, one would have to contribute patches to all the
>>> distributions (we care about, at least), and then nag the respective
>>> maintainers to include these patches.
>> 
>> Not true.  You just need to make sure that "setup.py install" creates
>> that database.  With the proposed format of the database this is just
>> a file in the correct location - exactly for this reason.  Next time
>> the distribution will build the package that database file will be in
>> place.
> 
> How so? Are you /sure/ the packaging process even *runs* setup.py?
> And if they do, why do you think they will pick up the database
> file?
> 

In the case of Fedora rpms, the usual install uses setup.py.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python source code on Bazaar vcs

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mar 20, 2008, at 5:49 PM, Christian Heimes 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)

Yep.  I've opened issue 2456 for this in the bug tracker.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+UdjnEjvBPtnXfVAQKQ8gQAuh8ynIbNXFaFEViQAvJ84M/D6Db4q008
X3XgoEq0wJWpjO2pA3lzDY0uuowkXGUMuhgMOQ6qeTz+1nDeazQPDdHwKr2wdNff
yBBG+3jstDdiwr9uGjRA39gpu/29JVE0Kxd9aMyOorW48RYX6wGcfbg1nGYkOO0u
haY0pWG4g+0=
=q6Yg
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Python source code on Bazaar vcs

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mar 21, 2008, at 5:28 PM, Paul Moore wrote:
>
> 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.

Yes, looms are awesome, I highly recommend you install the plugin and  
take a look.  There's a link to the loom plugin on 
.

I don't know much about Mercurial queues, but I've been told the  
feature is similar. I do have a lot of experience using Bazaar looms,  
and I'm a huge fan.

> 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 used it in Mailman work all the time, and I've been using it on the  
train home from Pycon for working on the email package in Python 3.0.   
Quick tutorial:

bzr branch http://code.python.org/python/3.0 my30feature
cd my30feature
bzr nickname upstream
bzr loomify
bzr create-thread firststuff

bzr commit
bzr create-thread secondstuff

bzr commit
bzr create thread thirdstuff

bzr commit
bzr down-thread secondstuff
# see what's different between secondstuff and firststuff
bzr diff -r thread:

rinse-and-repeat-ly y'rs,
- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+Ufb3EjvBPtnXfVAQI2ywP9GLK07pVEKmfb7K3s/I7oUnw3MA6uQPML
41rUi8fJQIIejPkmsKrrchSSkp3ZeSot4btxxXYD6G+HX3yzNgK3ydijZtpofIm1
dTIreCOYE9uGS6xk2Frj58rCrDwrsZ0eADyCZ4V18pBNEwpTsDw0wLFktqx2yzhH
BZBLqUy//NM=
=cuNj
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Phillip J. Eby]

At 11:00 AM 3/22/2008 +, Floris Bruynooghe wrote:
>As long as systems (dpkg, rpm, ...) install the .egg-info files they
>do communicate which modules/distributions are installed.  The
>installdb would just duplicate this information (according to the
>current PEP).

.egg-info/PKG-INFO don't list the specific files, though.


>There is a way of telling if you have to keep you hands off a package
>(sorry to bring this up again): installation paths.  /usr/lib is the
>system path, the local admin (and hence setuptools) should keep their
>hands off it at all times (unless requested with a --prefix or so for
>building the debs or rpms but an uninstall in those cases won't be
>required from setuptools).

As I mentioned previously, if the spec says anything about specific 
paths, it will be full of fail.  The spec MUST be able to work with 
*any* local policy about where Python packages are to be 
installed.  Otherwise, any tool that wants to work with install-dbs 
will end up accumulating a long list of paths to be handled specially 
for each OS vendor and version...  and still not handle everything.  No can do.

This has to be a mechanism, not a policy.  Vendors and admins should 
be able to enforce reasonable policies, without requiring that every 
tool have those policies built in.  For one thing, it's an entry 
barrier to tools.

Basically, what I'm proposing here is like WSGI for package 
management tools -- and building anything about paths into the spec 
would be like WSGI spelling out what pages should be at what URLs!

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Phillip J. Eby]

At 12:33 PM 3/22/2008 +0100, Martin v. Löwis wrote:
>>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.
>
>Something like a read-only flag?

Not exactly.  More like, "package management tool X claims exclusive 
rights to this package".  Python tools would always defer this right 
to the system packager, i.e. a system packager is not obliged to 
respect a Python tool's claim to a file, but not the other way around.

That way, system packaging tools don't need to do anything but mark 
the installed files as belonging to them.

Since most vendors at least *begin* with a "setup.py install", we 
could provide a way to indicate that the installation is being done 
on behalf of a system packaging tool, so that it can provide that indication.


>For those without the read-only flag, the specification should
>explicitly say what manipulation is allowed.

Since a distribution isn't really "mutable", I would think that 
uninstallation and reinstallation would be the only manipulation 
available.  (As distinct from inspection, verification, and other 
read-only activities.)

It's possible, though, that there might also be actions such as 
restoring or relocating scripts or data in shared locations outside 
of the sys.path directory.  That will get clearer as the spec gets defined.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mar 17, 2008, at 12:27 AM, Martin v. Löwis wrote:
>> 'critical' is fine (or 'immediate').  My problem before was that I   
>> couldn't do one query that gave me all the critical issues for  
>> both  2.6 and 3.0.  That certainly could have been pebkac though.   
>> Neal  mentioned that that kind of query should be possible, if it's  
>> not  already there.
>
> I just created a "Showstoppers" public query (go to Your Queries/ 
> *edit*,
> and set it to "leave in").
>
> This *just* searches for critical open issues, all versions. Given
> that there are currently really no critical issues, that semantically
> is the same as further restricting it to 2.6 and 3.0.
>
> Creating a query that searches for multiple versions is possible
> through URL editing, but not the form (currently). I'm not sure
> whether that would search for issues which are marked both 2.6
> and 3.0, or for issues that are either marked 2.6 *or* 3.0.

Thanks Martin, I think this will work for now.  Is there any way you  
can allow me to edit this query too?

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+UkDnEjvBPtnXfVAQItWgP9FF++/A19BvM4+wjf8xyV2oCbMa0KH1+D
ssTdA+pnB70c06CuGNe7Wf7OEGNNmJmMtGmTcHqa5irJc/BPVlOvZ4Uj9iC9qJKe
BW0P4BoCmQ1Dtap7tPa9ACb2+b0zwPLgXG3O/0WMwkG3sdeLYm6oscWYmXcYzF2V
do1rmkIAbmw=
=ziz3
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Phillip J. Eby]

At 02:14 PM 3/22/2008 +, Paul Moore wrote:
>For the system Python, I need:
>- a single way to list what's installed (including version)
>- a single way to uninstall items as needed
>- a way (or more than one) to install 3rd party software *which ties
>into the above*

Right, and the PEP effort is devoted to having one way to store the 
information required, to tie these things together.  If there is a 
standard way to store that info on your system, then it doesn't 
matter how many tools there are, you still have your "one way" to 
list what's installed or to uninstall things, because you just pick 
the one lister and/or uninstaller whose UI you prefer.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Martin v. Löwis]

>> For those without the read-only flag, the specification should
>> explicitly say what manipulation is allowed.
> 
> Since a distribution isn't really "mutable", I would think that 
> uninstallation and reinstallation would be the only manipulation 
> available.  (As distinct from inspection, verification, and other 
> read-only activities.)

Sure, but what is precisely the semantics of uninstallation, in
terms of changes to the system state?

I think any model where uninstallation is merely the removal
of files is too limited to be practical.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Martin v. Löwis]

> Thanks Martin, I think this will work for now.  Is there any way you can 
> allow me to edit this query too?

Not easily.

I could just remove it, and allow you to create a new one (or you create
one yourself, anyway, and I remove mine later).

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Phillip J. Eby]

At 11:19 AM 3/22/2008 -0400, Phillip J. Eby wrote:
>Not exactly.  More like, "package management tool X claims exclusive
>rights to this package".  Python tools would always defer this right
>to the system packager, i.e. a system packager is not obliged to
>respect a Python tool's claim to a file, but not the other way around.
>
>That way, system packaging tools don't need to do anything but mark
>the installed files as belonging to them.

This probably needs to be refined a little.  Exclusive right is too 
strong, and it goes against Paul Moore's desire for using a single 
tool.  Perhaps instead what it should be is an "uninstall warning" 
field that must be displayed to a user if an interactive program is 
doing uninstallation, and that a non-interactive program must refuse 
to uninstall unless explicitly requested to go ahead.

Unfortunately, a warning message might then need to be localized.  So 
this idea still needs some work.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Martin v. Löwis]

> I speak for Debian, so for Debian: yes.  The setup.py would have to be
> pretty bad for a packager to not use it.  There is no reason to
> re-write upstream's installation procedure as you would have to figure
> out which files need to be installed where and this would create many
> bugs.
> 
> The canonical way is something like this:
> 
>   $ pythonX.Y setup.py --root=$(pwd)/debian/tmp
>   $ # Fixup anything done wrong/badly (for debian) by setup.py
>   $ # Make a tarball of $(pwd)/debian/tmp
> 
> In reality it's slightly more complicated of course.

More than slightly so, with pycentral, pysupport, and all that.

I still doubt that the database would show up in a directory on
sys.path. IIUC, things get install into
/usr/share/pycentral/package, and then get symlinked into
/usr/lib/pythonX.Y/site-packages at installation time. It's
not all that clear to me how that deals with "non-regular"
files.

> At [1] there are
> many packages, paste and parallelpython are good examples if you're
> interested (look in the debian/rules file).

I started with nevow. It uses cdbs, so its debian/rules is nearly
empty, and does not include a call to setup.py at all.

Instead, the distutils support is in

/usr/share/cdbs/1/class/python-distutils.mk

where setup.py is invoked as

ifeq (,$(DEB_PYTHON_REAL_LIB_PACKAGES))
common-install-arch common-install-indep:: common-install-impl
common-install-impl::
 cd $(DEB_SRCDIR) && python$(DEB_PYTHON_COMPILE_VERSION) 
$(DEB_PYTHON_SETUP_CMD) install --root=$(DEB_DESTDIR) 
$(DEB_PYTHON_INSTALL_ARGS_ALL) $(DEB_PYTHON_INSTALL_ARGS_$(cdbs_curpkg))
else
$(patsubst %,install/%,$(DEB_PYTHON_REAL_LIB_PACKAGES)) :: install/% :
 cd $(DEB_SRCDIR) && python$(cdbs_python_ver) 
$(DEB_PYTHON_SETUP_CMD) install --root=$(CURDIR)/debian/$(cdbs_curpkg) 
$(DEB_PYTHON_INSTALL_ARGS_ALL) $(DEB_PYTHON_INSTALL_ARGS_$(cdbs_curpkg))
endif

$(patsubst %,install/%,$(DEB_PYTHON_SIMPLE_PACKAGES)) :: install/% :
 cd $(DEB_SRCDIR) && python $(DEB_PYTHON_SETUP_CMD) install 
--root=$(CURDIR)/debian/$(cdbs_curpkg) $(DEB_PYTHON_INSTALL_ARGS_ALL) 
$(DEB_PYTHON_INSTALL_ARGS_$(cdbs_curpkg))

I cannot infer from that whether supplying a package database
snippet in setup.py would actually work.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Paul Moore]

On 22/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> This probably needs to be refined a little.  Exclusive right is too
>  strong, and it goes against Paul Moore's desire for using a single
>  tool.

Huh? How's that? Don't forget that I'm on Windows, and on Windows
there is no "system tool" - just bdist_wininst, bdist_msi and
easy_install. The fact that bdist_wininst and bdist_msi link into the
system UI for listing and uninstallation doesn't make packages using
them "system packages". If easy_install put add/remove program info in
place, my "single tool" would be the add/remove list. If something
else (for example, the proposed index of installed package, with a
suitable UI) is deemed the "single tool", then bdist_wininst and
bdist_msi have to be changed to respect that.

The only fly in this ointment is bdist_msi, which uses MSI format,
which is a lot nearer to a Windows "system packager" than anything
else. Whether that means bdist_msi can't be changed to work with a
package index rather than (or as well as, I don't care) add/remove, I
don't know.

>  Unfortunately, a warning message might then need to be localized.  So
>  this idea still needs some work.

The "one way to do it" uninstaller should be able to uninstall
everything. If it needs to call the system uninstaller for a specific
package, there's nothing wrong with doing that. But why tell me to run
a different command? Just do it for me. I only want one UI, the rest
is implementation detail.

(Others may have different preferences, so a choice may need to be
made. If so, and if it goes against me, fair enough, I have to decide
what to do about that for myself. But I'd rather force people to tell
me "no", than leave people thinking they satisfied me and wondering
why I'm still complaining...)

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Phillip J. Eby]

At 04:29 PM 3/22/2008 +0100, Martin v. Löwis wrote:
>>>For those without the read-only flag, the specification should
>>>explicitly say what manipulation is allowed.
>>Since a distribution isn't really "mutable", I would think that 
>>uninstallation and reinstallation would be the only manipulation 
>>available.  (As distinct from inspection, verification, and other 
>>read-only activities.)
>
>Sure, but what is precisely the semantics of uninstallation, in
>terms of changes to the system state?
>
>I think any model where uninstallation is merely the removal
>of files is too limited to be practical.

The distutils only support the *addition* of files, so I'm not sure 
how only removing files is a limit here.  Could you explain?




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Martin v. Löwis]

> In the case of Fedora rpms, the usual install uses setup.py.

Ok. Does it then also package all files that get installed into
the RPM file? If it produces multiple RPMs from a single source
package, how does it know which files go into what RPM?

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 project management

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mar 22, 2008, at 11:31 AM, Martin v. Löwis wrote:
>> Thanks Martin, I think this will work for now.  Is there any way  
>> you can allow me to edit this query too?
>
> Not easily.
>
> I could just remove it, and allow you to create a new one (or you  
> create
> one yourself, anyway, and I remove mine later).

Naw, no need for the extra work.  Thanks!
- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR+UpvnEjvBPtnXfVAQLHDAP/WVC9IJpGbe0RgoG/5AkWki0AioEvvrPL
2i9+wSPJYXmNz1960tpH+iehjEtkxdCHFNSbSP9BAB71ANRQXJtpxcibNvdHnF55
yWI7lM/Qt1NMYyUD4vn8HDNSMLFSQqztvkCm4OmkzhO/ZdODp4kHdUUfhn7ggC72
jzSq9Qt9eJY=
=4xE2
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Martin v. Löwis]

> 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.

I think this was all captured in amk's statement "RPM-like
verification". RPM not only verifies file content, but also whether
the permissions are all correct. So if the administrator mistakenly
does a chown -R on a subtree, he can get back to what it was with
the package manager, without having to reinstall everything, or can
atleast find out what packages he broke.

IIUC, the Solaris package manager provides the same feature.

MSI provides a "repair installation", which doesn't really check
anything, but reruns the entire installation (and then skipping
those files who passed the checksum test, where checksums had
been recorded in the MSI).

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Martin v. Löwis]

Neal Becker wrote:
> Another use case, which I find in my world, is that there are always
> packages that interest me (found at pypi), that my vendor hasn't packaged
> as rpms yet.
> 
> With finite resources, this will always be true.

Why do you need a package database for that? Can't you just run
"setup.py install", or perhaps "setup.py bdist_rpm", and then install
the RPM?

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Martin v. Löwis]

> Huh? How's that? Don't forget that I'm on Windows, and on Windows
> there is no "system tool" - just bdist_wininst, bdist_msi and
> easy_install. The fact that bdist_wininst and bdist_msi link into the
> system UI for listing and uninstallation doesn't make packages using
> them "system packages".

In pje's terminology, they do. He uses "system package" as a shorthand
for "package in a format defined by the system vendor", not as
"package supplied by the system vendor" (IIUC). So .msi files and
self-extracting .exe files are all "system packages", as opposed to
.eggs (which are in a format that wasn't defined by the system vendor).

> The only fly in this ointment is bdist_msi, which uses MSI format,
> which is a lot nearer to a Windows "system packager" than anything
> else. Whether that means bdist_msi can't be changed to work with a
> package index rather than (or as well as, I don't care) add/remove, I
> don't know.

If the package database is merely a directory with additional files
in it, one file per package, then most likely both bdist_wininst
and bdist_msi could support that.

If the file needs to contain file names specific to the target system,
then supporting it in bdist_msi is a bit tricky, as one would have
to generate the file at installation time. That's a "custom action";
I'd probably generate a VB script at packaging time which is then run
at installation time to edit the package database.

> The "one way to do it" uninstaller should be able to uninstall
> everything. If it needs to call the system uninstaller for a specific
> package, there's nothing wrong with doing that. But why tell me to run
> a different command? Just do it for me. I only want one UI, the rest
> is implementation detail.

The uninstallation procedure of the system installer probably has
a separate UI which can't really be suppressed.

For example, uninstallation may be rejected as additional applications
rely on the package, or uninstallation could cause automatic removal
of prerequisite packages that are then no longer used, all requiring
user confirmation.

Also, on some systems, it's difficult to know what specific tool
to run to interact with the system packaging. On some systems,
you have a choice of multiple command-line, text mode, and GUI
tools, some of which may not be installed, or may fail to work
(e.g. when you don't have the windowing system running, and the
tool is a windowed one), or may not be the user's preference.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Martin v. Löwis]

>> Sure, but what is precisely the semantics of uninstallation, in
>> terms of changes to the system state?
>>
>> I think any model where uninstallation is merely the removal
>> of files is too limited to be practical.
> 
> The distutils only support the *addition* of files, so I'm not sure 
> how only removing files is a limit here.  Could you explain?

For files, yes, it only supports addition. But it supports
arbitrary other actions, such as:
- addition of registry keys
- addition of user accounts
- creation of database tables in a relational database
- updating the shared library loader path
- creation and start of a system service
- integration of documentation into info
- registration of DTDs with the system catalog
- ...

It's turing-complete, and it has full interface to the operating
system, so installation of a distutils package can do *much*
more than merely installing files.

Uninstallation needs to revert anything installation did,
so it is often more than mere removal of files.

HTH,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Martin v. Löwis]

> Oh, and application installation is (should be) completely different.
> On Windows, applications should probably be bundled with their own
> Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
> standard is, so I'd have to defer to others.

This I disagree with. I think it's an overall bad thing to have all
kinds of applications ship their own copy of Python; see also Aza
Raskin's PyCon keynote.

On Linux, python typically comes with the system pre-installed;
it is not even an option not to have it, except for minimalist
installations. So if you write python scripts, you typically
expect that #!/usr/bin/env python works; you might put python2.5
there if you don't trust that system one is "good enough".

For installing the application, you typically want the choice
between a "system installation" (in /usr/bin, or perhaps
/usr/local/bin), and a "user installation". As distutils supports
both cases, it works fairly well for applications as well.

Regards,
Martin



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal: Slightly Changed Semantics for from-Import

[Martin v. Löwis]

> If a test case is needed I can attach one later on.

You should put all this into bugs.python.org, preferably with
a patch implementing it also.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Christian Heimes]

Guido van Rossum schrieb:
> Right. We've done this 2-stage rename before, during the great
> (sometimes known as grand) renaming, in the 1.x days.

I haven't been around during the 1.x -> 2.x days. I was still in the
dark ages (aka PHP user).

How do you want me to tackle down the PyString / PyBytes problem?

Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Editing "public" queries in tracker [was: ... project management]

[Stephen J. Turnbull]

I think this howto is of general interest to the community, but I'm
crossposting to Tracker-Discuss and redirecting discussion there.
Reply-To set.

Barry Warsaw writes:

 > Thanks Martin, I think this will work for now.  Is there any way you  
 > can allow me to edit this query too?

While as Martin says only the author can edit a query, you can (in
Roundup 1.4.2, which bugs.python.org may not have yet?) edit a copy of
that query.  (Since a query is an object, you can keep the same name
for multiple queries.  **But:** This is a doubleplusungood idea
unless you coordinate with the first author to remove one of the
versions, because there is no way to distinguish multiple queries by
the same name except whether they are editable or not.)

What I see in the edit interface at first is

Query   Include ... Edit  Private ...
YourQuery_[not yours to edit]

(where trailing _ indicates a link and <> a GUI widget).  After
setting YourQuery "leave in: yes", I see

Query   Include ... Edit  Private ...
YourQuery_edit_  [delete]
YourQuery_[not yours to edit]

ie, it looks like Roundup automatically makes a copy for you to edit.
Urk ... once I've edited it, I now see

Query   Include ... Edit  Private ...
YourQuery_edit_  [delete]
YourQuery_edit_  [delete]
YourQuery_[not yours to edit]

where one of the editables is my version, and the other a copy of the
original query You wrote.  So even the editor is likely to find it
confusing unless he renames his new version.

Also, in 1.4.2 there seems to be a bug, such that my ordinary User was
unable retire or remove the query.  For now, you may not want to do
this a lot as your sidebar will get cluttered.

I wonder if it might be a good idea to have a convention to
distinguish public queries that may be used as templates?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Paul Moore]

On 22/03/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Oh, and application installation is (should be) completely different.
>  > On Windows, applications should probably be bundled with their own
>  > Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
>  > standard is, so I'd have to defer to others.
>
>
> This I disagree with. I think it's an overall bad thing to have all
>  kinds of applications ship their own copy of Python; see also Aza
>  Raskin's PyCon keynote.

Is this on Windows? It's fairly common practice. Can you give me a
pointer to Aza Raskin's keynote? Is it online anywhere? I'd be
interested in his point of view.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Martin v. Löwis]

>>> Oh, and application installation is (should be) completely different.
>>  > On Windows, applications should probably be bundled with their own
>>  > Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
>>  > standard is, so I'd have to defer to others.
>>
>>
>> This I disagree with. I think it's an overall bad thing to have all
>>  kinds of applications ship their own copy of Python; see also Aza
>>  Raskin's PyCon keynote.
> 
> Is this on Windows? It's fairly common practice.

Unfortunately so, yes. This can be viewed a burden to the adoption
of Python: for a small application, you get this huge download to
bundle.

> Can you give me a
> pointer to Aza Raskin's keynote? Is it online anywhere? I'd be
> interested in his point of view.

Unfortunately no. I was looking for it, but couldn't find it. He
mentioned a website with a "call for action", but I couldn't find
that, either :-(

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Guido van Rossum]

>  I haven't been around during the 1.x -> 2.x days. I was still in the
>  dark ages (aka PHP user).

:-)

>  How do you want me to tackle down the PyString / PyBytes problem?

I think it can actually be simplified. I think maintaining binary
compatibility between 2.6 and earlier versions is hopeless anyway, so
we might as well just rename PyString to PyBytes in 2.6 and 3.0, and
have an extra set of macros so that code using PyString needs to be
recompiled but not otherwise touched. E.g.

typedef { ... } PyBytesObject;
#define PyStringObject PyBytesObject

... PyString_Type;
#define PyBytes_Type PyString_Type



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Making sys.py3k_warning writable

[Steven Bethard]

Right now, test_py3kwarn only runs if the test suite is run using the
-3 command line flag to Python. So for most regrtest runs (e.g. the
buildbots) this test will never be run.

 It would be nice to be able to turn the flag on from Python (e.g.
within test_py3kwarn). Is that possible?  Here's what I tried and it
didn't seem to work::

$ python_d.exe
Python 2.6a1+ (trunk:61715M, Mar 21 2008, 14:33:00) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.py3k_warning = True; callable(int)
True

And here's what happens when you specify -3 at the command line:

$ python_d.exe -3
Python 2.6a1+ (trunk:61715M, Mar 21 2008, 14:33:00) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> callable(int)
__main__:1: DeprecationWarning: callable() not supported in 3.x. Use
hasattr(o, '__call__').
True

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
 --- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Making sys.py3k_warning writable

[Benjamin Peterson]

On Sat, Mar 22, 2008 at 3:34 PM, Steven Bethard <[EMAIL PROTECTED]>
wrote:

> Right now, test_py3kwarn only runs if the test suite is run using the
> -3 command line flag to Python. So for most regrtest runs (e.g. the
> buildbots) this test will never be run.
>
>  It would be nice to be able to turn the flag on from Python (e.g.
> within test_py3kwarn). Is that possible?  Here's what I tried and it
> didn't seem to work::

That's because sys.py3kwarning is set on startup from Py_Py3kWarningFlag and
never checked again. Either we should make it immutable or fix it.

>
>
> $ python_d.exe
> Python 2.6a1+ (trunk:61715M, Mar 21 2008, 14:33:00) [MSC v.1500 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys; sys.py3k_warning = True; callable(int)
> True
>
> And here's what happens when you specify -3 at the command line:
>
> $ python_d.exe -3
> Python 2.6a1+ (trunk:61715M, Mar 21 2008, 14:33:00) [MSC v.1500 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> callable(int)
> __main__:1: DeprecationWarning: callable() not supported in 3.x. Use
> hasattr(o, '__call__').
> True
>
> Steve
> --
> I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
> tiny blip on the distant coast of sanity.
>  --- Bucky Katt, Get Fuzzy
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Martin v. Löwis]

> I think it can actually be simplified. I think maintaining binary
> compatibility between 2.6 and earlier versions is hopeless anyway

ABI-wise or API-wise?

I would surely hope that the 2.6 API is "mostly" compatible with the
2.5 API.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Making sys.py3k_warning writable

[Martin v. Löwis]

Steven Bethard wrote:
> Right now, test_py3kwarn only runs if the test suite is run using the
> -3 command line flag to Python. So for most regrtest runs (e.g. the
> buildbots) this test will never be run.

For the buildbots, it would be easy to turn -3 on, though.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6 and 3.0 tasks

[Christian Heimes]

Guido van Rossum schrieb:
>>  When the new buffer protocol is available in 2.6 we can start back
>>  porting bytesarray and the new IO framework.
> 
> Are these really so closely tied that they have to wait before they
> can be backported?

I've started with the backport of the bytearray type in a new branch

  svn+ssh://[EMAIL PROTECTED]/python/branches/trunk-bytearray

Any help is appreciated. I already solved most issues.

Open tasks:

 * fix bytearray.extend()

 * add PyString support to bytearray.fromhex

 * Add old style char buffer interface to bytearray (for codecs)

 * Add old style read write buffer interface to bytearray (for
file.readinto)

 * Fix pickle and copy support for bytearray

Christian




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Making sys.py3k_warning writable

[Benjamin Peterson]

On Sat, Mar 22, 2008 at 3:58 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:

> Steven Bethard wrote:
> > Right now, test_py3kwarn only runs if the test suite is run using the
> > -3 command line flag to Python. So for most regrtest runs (e.g. the
> > buildbots) this test will never be run.
>
> For the buildbots, it would be easy to turn -3 on, though.

Should I work a patch to allow Python code to disable/enable the flag?

>
>
> Regards,
> Martin
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Making sys.py3k_warning writable

[Martin v. Löwis]

> For the buildbots, it would be easy to turn -3 on, though.
> 
> Should I work a patch to allow Python code to disable/enable the flag?

+0.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Making sys.py3k_warning writable

[Benjamin Peterson]

On Sat, Mar 22, 2008 at 4:08 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:

> > For the buildbots, it would be easy to turn -3 on, though.
> >
> > Should I work a patch to allow Python code to disable/enable the flag?
>
> +0.

See issue 2458.

>
>
> Regards,
> Martin
>



-- 
Cheers,
Benjamin Peterson
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] State of N-dimensional array interface

[Mike Sullivan]

What is the current state of the N-D Array Interface proposal
(http://numpy.scipy.org/array_interface.shtml). Some work was done on
this in an earlier Summer of Code, but it seems to never have been
included. Does anybody know what state that work is in and what
prevented it's inclusion?

(I am interested in completing this as a Summer of Code project. I
posted about this on the SOC list, and received a suggestion to try
asking python-dev.)

-- 
Mike Sullivan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Two questions about jump opcodes

[Antoine Pitrou]

Hi,

I'm attempting some bytecode tweaks (see http://bugs.python.org/issue2459) and
I've got two questions about jump instructions:

- Why are there both relative and absolute jump instructions? The traditional
rationale for relative jumps (apart from position-independent code) is to allow
for shorter operand sizes; but Python opcodes all have the same operand size
(and 16 bits is more than enough to address most bytecode arrays).
- Why are relative jumps unsigned? This means they can only jump forward, and as
soon as you want to jump backward you have to switch to an absolute jump...

(in that regard, I don't understand what JUMP_FORWARD can possibly bring over
JUMP_ABSOLUTE)

Thanks for your kind answers

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Two questions about jump opcodes

[skip]

Antoine> - Why are there both relative and absolute jump instructions?

The best place to search for the reasons behind this is Python/compile.c.
(JUMP_ABSOLUTE can jump backwards.)  There have been lots and lots of
changes to the Python virtual machine the past few years.  When trying to
understand the basic concepts it might be best to check out a very old
version of the code from Subversion (1.5.2, 2.0, 2.1, etc).  Those versions
have many fewer optimizations, so it's likely that compile.c and ceval.c
will be more readable.  (My full understanding of the virtual machine
probably ended with 1.5.2.)  That should give you a basic understanding of
how things work without the obfuscation added by the many optimizations.
You can then move to more recent versions and more easily see what's going
on, even in the face of all the optimizations.

Antoine> (in that regard, I don't understand what JUMP_FORWARD can
Antoine> possibly bring over JUMP_ABSOLUTE)

Well, you can't chain jumps together with the latter.  If, for some reason,
you needed to jump forward more than 16kbytes you could accomplish that with
multiple JUMP_FORWARD opcodes.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Two questions about jump opcodes

[Phillip J. Eby]

At 10:43 PM 3/22/2008 +, Antoine Pitrou wrote:
>- Why are there both relative and absolute jump instructions? The traditional
>rationale for relative jumps (apart from position-independent code) 
>is to allow
>for shorter operand sizes; but Python opcodes all have the same operand size

Actually they don't.  They can have 32-bit arguments, with the 
EXTENDED_ARG opcode.  EXTENDED_ARG loads the high 16 bits of the 
argument in the opcode that immediately follows.

>(and 16 bits is more than enough to address most bytecode arrays).

Ah, but not *all* bytecode arrays.  Apparently some (automatically 
generated) code at LucasFilm (if memory serves) exceeded some of the 
16-bit limits for bytecode, so the EXTENDED_ARG opcode was added to fix this.


>- Why are relative jumps unsigned? This means they can only jump 
>forward, and as
>soon as you want to jump backward you have to switch to an absolute jump...

With a backward jump, you already know the exact offset, so you know 
if you need a 16-bit or 32-bit operand.


>(in that regard, I don't understand what JUMP_FORWARD can possibly bring over
>JUMP_ABSOLUTE)

It means you don't have to guess whether your jump target is going to 
cross the 64K boundary, thereby requiring you to have used a 32-bit 
operand.  Of course, it does limit your forward jumping to skipping 
no more than a 64K block, but apparently nobody has exceeded that 
limit yet.  :)  Merely having 64K of total bytecode is presumably an 
easier limit to reach than *jumping over* 64K worth of bytecode.  :)

In truth, I don't know if that's really the reason why things were 
originally set up this way, but these are certainly among the reasons 
thing will probably stay this way.  :) 

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Two questions about jump opcodes

[Antoine Pitrou]

Wow, thanks to both of you (Phillip & Skip) for the fast answers.
Just in case anyone has time to spare, I have more pesky questions (and a
working patch :-)) in the aforementioned bug entry
(http://bugs.python.org/issue2459).

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com