Update to Python Documentation Website Request

[David Lyon]

Hi Greg,

I'm on the python-dev mailing list and somebody gave me a link
to a page that you have done:

http://docs.python.org/install/

Can I ask that you also provide a link for windows users
to my project:

http://sourceforge.net/projects/pythonpkgmgr/

Our project provides an alternative to command line installation.

And can save a lot of time for users when they wish to
install packages.

Thanks

David

[Martin v. Löwis]

Post by David Lyon
Can I ask that you also provide a link for windows users
http://sourceforge.net/projects/pythonpkgmgr/

I fail to see how this project is relevant in the context
of explaining distutils. So you would have to come up with
a proposal of specific wording that makes the relevance more
apparent.

Please provide a patch to bugs.python.org.

Regards,
Martin

[Ben Finney]

Post by David Lyon
I'm on the python-dev mailing list and somebody gave me a link
http://docs.python.org/install/

That's a document describing how to use ‘distutils’, which is what every
recipient of Python will already have installed.

Post by David Lyon
Can I ask that you also provide a link for windows users
http://sourceforge.net/projects/pythonpkgmgr/

That doesn't seem at all appropriate; promoting third-party packages
isn't at all what the above document should be doing.

Post by David Lyon
Our project provides an alternative to command line installation.

If people want an alternative to the standard tools provided in Python,
the documentation for Python itself is not the right place to be
looking. The Python Package Index <URL:http://pypi.python.org/> is the
right place to be promoting (free-software) third-party tools.

[d***@preisshare.net]

That's a document describing how to use âdistutilsâ, which is what
every
recipient of Python will already have installed.

Post by David Lyon
Can I ask that you also provide a link for windows users
http://sourceforge.net/projects/pythonpkgmgr/

That doesn't seem at all appropriate; promoting third-party packages
isn't at all what the above document should be doing.

Distutils was once seperate and was then included in the standard python.

So i guess that I am working with the same goal in mind.

If people want an alternative to the standard tools provided in Python,

The Python Package Index <URL:http://pypi.python.org/> is the

right place to be promoting (free-software) third-party tools.

Well I can sure try that and thank you for the tip.

Btw, at the moment there exists no inbuilt mechanism within python for
retrieving packages from pypi.

Imho this is an omission for a so called 'batteries included' language.

Distutils is a builtin module for 'pushing' a developer package 'to' pypi.

But there is no corresponging mechanise for a user to 'pull' packages back.

Surely this is a gap in the standard distro?

So it is not inappropriate for me to ask about this on this list.

Take care

David

[Ben Finney]

Post by d***@preisshare.net

Post by Ben Finney

Post by David Lyon
Can I ask that you also provide a link for windows users
http://sourceforge.net/projects/pythonpkgmgr/

That doesn't seem at all appropriate; promoting third-party packages
isn't at all what the above document should be doing.

Distutils was once seperate and was then included in the standard python.
So i guess that I am working with the same goal in mind.

In which case you should work to get it accepted into standard Python
*before* asking for it to be promoted in the standard Python
documentation.

Post by d***@preisshare.net
So it is not inappropriate for me to ask about this on this list.

Discussing it here is appropriate. The modification you request is not,
IMO.

[David Lyon]

Post by Ben Finney
In which case you should work to get it accepted into standard Python
*before* asking for it to be promoted in the standard Python
documentation.

I'm very interested in how I would go about doing that.

Die-hard users probably know all the python issues relating to
package installation and appear to have thick skins. An "easy-way"
might not mean to much to them because they've settled down into
their own comfort zone.

But new users, who's first operating system comes complete with a
polished GUI, have an expectation for having a polished GUI tool
to download their python packages in.

Under Windows, we get IDLE. And ActiveState as I understand are
working on their own package manager for their own python distribution.

So maybe it is appropriate to consider having a GUI Package Manager
within at least the Windows distribution of Python.

Yes, please tell me the process...

I'm very interested.

David

[Nick Coghlan]

Post by d***@preisshare.net
Distutils is a builtin module for 'pushing' a developer package 'to' pypi.
But there is no corresponging mechanise for a user to 'pull' packages back.
Surely this is a gap in the standard distro?
So it is not inappropriate for me to ask about this on this list.

Raising it without at least glancing at the list archives which hold
copious amounts of virtual text on that topic is somewhat inappropriate
though :)

Cheers,
Nick.

P.S.
http://www.google.com/search?q=site:mail.python.org+inurl:python-dev+easy_install

[d***@preisshare.net]

Post by Nick Coghlan
Raising it without at least glancing at the list archives which hold
copious amounts of virtual text on that topic is somewhat inappropriate
though :)

Well I have consulted every available expert on the distutils list to the
point where I feel 'up' with the issues at hand.

They're great people.. And as helpful as they possibly can be..

But surely Python isn't only about archives and age old problems.

Sure they might be there.. So lets get in and fix them..

Which is totally what i'm attempting to do at the moment even if packaging
isnt perceived as being the most interesting part of python develepment
going on today.

Inapropriate or not, i want to donate my time to it.. Because i think we
need 'fresh' thinking - not archive regurgitation.


David

[Nick Coghlan]

Received: from localhost.localdomain (HELO mail.python.org) (127.0.0.1)
by albatross.python.org with SMTP; 23 Jul 2009 14:30:45 +0200
X-policyd-weight: using cached result; rate: -8.4
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234])
by mail.python.org (Postfix) with ESMTP
for <python-***@python.org>; Thu, 23 Jul 2009 14:30:44 +0200 (CEST)
Received: by rv-out-0506.google.com with SMTP id f6so256628rvb.1
for <python-***@python.org>; Thu, 23 Jul 2009 05:30:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:received:received:message-id:date:from
:user-agent:mime-version:to:cc:subject:references:in-reply-to
:x-enigmail-version:content-type:content-transfer-encoding;
bh=+3DgjwoCo/3rx7EiBFcXnbhhSpA27wuY/5fjEQMmjT4=;
b=u9s0sP64N3edVFCot5HylGcADZLXeCcydZeB1iq47dBA+/7Ciz821M+kHXkL7iBesI
Z6sP1K+t4IrzMr/KTTiWygQ0um2wb0NUuK2vWlTGZqm88aTzkOEOpt/vMk4WOgHz9mwN
iU677ZXPuLn/GQGRSQgBsm2Ml35d+0CNskVYw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=message-id:date:from:user-agent:mime-version:to:cc:subject
:references:in-reply-to:x-enigmail-version:content-type
:content-transfer-encoding;
b=IpoZEK9aJvbkdDc4uCGwoQ+kew4ofdFdesd2THUUx+OnGKluT3gOylRE01xUDtOkiK
IRM4wvqDl8nsqeDkx9bs/wf4jcCR6XEYuJQGKpAh9NJHEGs4CtyYyMWFaS16v0uhPM3M
Znz9Om81QKB/sc5LQcPV092LM7WW0XYAB03EA=
Received: by 10.141.3.2 with SMTP id f2mr1490458rvi.251.1248352239179;
Thu, 23 Jul 2009 05:30:39 -0700 (PDT)
Received: from ?192.168.0.2? (123-243-168-23.static.tpgi.com.au
[123.243.168.23])
by mx.google.com with ESMTPS id f21sm11752612rvb.2.2009.07.23.05.30.36
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Thu, 23 Jul 2009 05:30:38 -0700 (PDT)
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
In-Reply-To: <***@syd-srv02.ezyreg.com>
X-Enigmail-Version: 0.96.0
X-BeenThere: python-***@python.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Python core developers <python-dev.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/options/python-dev>,
<mailto:python-dev-***@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-dev>
List-Post: <mailto:python-***@python.org>
List-Help: <mailto:python-dev-***@python.org?subject=help>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-dev>,
<mailto:python-dev-***@python.org?subject=subscribe>
Sender: python-dev-bounces+python-python-dev=***@python.org
Errors-To: python-dev-bounces+python-python-dev=***@python.org
Archived-At: <http://permalink.gmane.org/gmane.comp.python.devel/105541>

Post by d***@preisshare.net

Post by Nick Coghlan
Raising it without at least glancing at the list archives which hold
copious amounts of virtual text on that topic is somewhat inappropriate
though :)

Well I have consulted every available expert on the distutils list to the
point where I feel 'up' with the issues at hand.

If you're actually up to speed with the issues, then I apologise. It was
just something of a novelty to see the topic brought up without
easy_install and setuptools even getting a mention.

However, the reason for the asymmetry has less to do with code
(easy_install exists after all) and more to do with the complexities of
system administration.

Providing a native ability to download and install packages from PyPI is
a major maintenance commitment due to a couple of major issues:

1. Providing an installation mechanism that is compatibility with a wide
variety of package management systems across at least Windows, Mac OS X
and the assorted flavours of *nix (Linux RPM, Linux APT, Solaris, *BSD,
etc, etc).

distutils cops a lot of heat already for not playing nicely with distro
packages. easy_install is loathed even more by many system
administrators (and that loathing often appears to flow over onto other
parts of setuptools).

2. There are some serious security implications in providing a native
mechanism for downloading, installing and running code in a
non-sandboxed environment.

The latter problem is probably the more technical of the two, but both
pose fairly complex social issues as well in terms of getting agreement
across disparate groups.

Cheers,
Nick.

[Jesse Noller]

Post by d***@preisshare.net

Post by Nick Coghlan
Raising it without at least glancing at the list archives which hold
copious amounts of virtual text on that topic is somewhat inappropriate
though :)

Well I have consulted every available expert on the distutils list to the
point where I feel 'up' with the issues at hand.
They're great people.. And as helpful as they possibly can be..
But surely Python isn't only about archives and age old problems.
Sure they might be there.. So lets get in and fix them..
Which is totally what i'm attempting to do at the moment even if packaging
isnt perceived as being the most interesting part of python develepment
going on today.
Inapropriate or not, i want to donate my time to it.. Because i think we
need 'fresh' thinking - not archive regurgitation.
David

Then why not include pip, easy_install, and this bash script I use to
install packages into core? The more the merrier, right?

Answer: None of these are standards, and as nick points out, there's
issues with sysadmins, security, and other things. Not to mention
they're fundamentally not part of the language.

At the language summit, this was hashed out quite a bit. I think most
everyone agreed that tools like easy_install, pip, virtualenv,
zc.buildout, etc simply do not belong in core python. The
"installation" landscape varies from platform to platform, it can run
full in the face of people who just want to use apt or yum, etc.

What *does* belong in core (distutils) however, and is something Tarek
has been working on, are APIs/Hooks/standards for tools like the ones
I've mentioned, and yours, to be able to do their job better, cleaner
and easier. Standards on metadata, uninstall hooks, etc are what the
stdlib should provide, not applications and tools built on top of
those things.

IMHO, the only "binary" python-core itself should "ship" is the python
binary itself (and pydoc, maybe :-)) - everything else should be built
with the idea of making integration with internals easier and
standard. That way OS package maintainers can hook into these APIs
(because they don't want to use something "non standard" to them),
people such as yourself can build GUI apps for downloading and
managing things, etc.

I know you want to help, and I don't think anyone is discouraging that
- but I think instead of solely focusing on your application is a
mistake. The bulk of the effort should be spent helping Tarek and
others "fix" distutils and spraying down bikeshedders so progress can
be made.

jesse

[Sridhar Ratnakumar]

Post by Jesse Noller
Then why not include pip, easy_install, and this bash script I use to
install packages into core? The more the merrier, right?
Answer: None of these are standards, and as nick points out, there's
issues with sysadmins, security, and other things. Not to mention
they're fundamentally not part of the language.
At the language summit, this was hashed out quite a bit. I think most
everyone agreed that tools like easy_install, pip, virtualenv,
zc.buildout, etc simply do not belong in core python.

Once PEP 376 is implemented, my suggestion is to at least link to these
tools (if not write a paragraph) as way of pointing users to alternative
package managers that uses the 'uninstall' API. A mention of PyPI would
also be helpful.

-srid

[Brett Cannon]

On Fri, Jul 24, 2009 at 11:47, Sridhar Ratnakumar

Post by Jesse Noller
Then why not include pip, easy_install, and this bash script I use to

Post by Jesse Noller
install packages into core? The more the merrier, right?
Answer: None of these are standards, and as nick points out, there's
issues with sysadmins, security, and other things. Not to mention
they're fundamentally not part of the language.
At the language summit, this was hashed out quite a bit. I think most
everyone agreed that tools like easy_install, pip, virtualenv,
zc.buildout, etc simply do not belong in core python.

Once PEP 376 is implemented, my suggestion is to at least link to these
tools (if not write a paragraph) as way of pointing users to alternative
package managers that uses the 'uninstall' API. A mention of PyPI would also
be helpful.

You can put that in the wiki, but it does not belong in the core
documentation (except the PyPI mention as we do control that). That simply
becomes a maintenance nightmare for use as we then have to keep up with the
releases of external tools that we have no direct connection with. Plus it
also give the illusion that Python has blessed these tools when in fact we
have not.

-Brett

[Christian Heimes]

Post by d***@preisshare.net

That's a document describing how to use âdistutilsâ, which is what
every
recipient of Python will already have installed.

Post by David Lyon
Can I ask that you also provide a link for windows users
http://sourceforge.net/projects/pythonpkgmgr/

That doesn't seem at all appropriate; promoting third-party packages
isn't at all what the above document should be doing.

Distutils was once seperate and was then included in the standard python.
So i guess that I am working with the same goal in mind.

I'm sorry to inform you that a wxWindows based solution has zero change
to get into the Python standard library ever. We are not going to add
another GUI toolkit to the core distribution. We might even remove TK
from the core and ship it as a separate package like bsddb3.

Christian

[David Lyon]

Post by Christian Heimes
I'm sorry to inform you that a wxWindows based solution has zero change
to get into the Python standard library ever. We are not going to add
another GUI toolkit to the core distribution.

In executable form, the Package Manager does not require wxWidgets
to be installed.

There is no dependency for this to be installed.

I'm not requesting that wxPython be added to the standard python
distribution.

Post by Christian Heimes
We might even remove TK
from the core and ship it as a separate package like bsddb3.

That doesn't affect the Python Package Manager in any way.

David

[Georg Brandl]

Post by David Lyon

Post by Christian Heimes
I'm sorry to inform you that a wxWindows based solution has zero change
to get into the Python standard library ever. We are not going to add
another GUI toolkit to the core distribution.

In executable form, the Package Manager does not require wxWidgets
to be installed.
There is no dependency for this to be installed.

What does "in exectuable form" mean?

Georg

[Paul Moore]

Post by Georg Brandl

Post by David Lyon

Post by Christian Heimes
I'm sorry to inform you that a wxWindows based solution has zero change
to get into the Python standard library ever. We are not going to add
another GUI toolkit to the core distribution.

In executable form, the Package Manager does not require wxWidgets
to be installed.
There is no dependency for this to be installed.

What does "in exectuable form" mean?

I read this as meaning that David was proposing to ship a built
application (on Windows, bundled up with something like py2exe, I
guess) and any supporting DLLs such as the wxWindows ones would be
bundled in, but the wxPython package would *not* be shipped as part of
the standard library.

If my assumption is right, that makes the package manager
inappropriate for shipping with Python, whether or not there are other
issues.

In my view, for an "application" to be shipped with Python, whether it
be Idle, or a package manager, or pydoc, or whatever, it must:
- be written as a Python script
- depend only on packages shipped with the standard library

That is before any considerations of the value of the application itself.

Given that David's package manager uses setuptools to do the installs
(and now it appears it uses wxPython for its GUI) that immediately
disqualifies it for inclusion in my view - regardless of its value as
a package.

Paul.

[David Lyon]

Post by Paul Moore
I read this as meaning that David was proposing to ship a built
application (on Windows, bundled up with something like py2exe, I
guess) and any supporting DLLs such as the wxWindows ones would be
bundled in, but the wxPython package would *not* be shipped as part of
the standard library.

That's correct.

Post by Paul Moore
In my view, for an "application" to be shipped with Python, whether it
- be written as a Python script
- depend only on packages shipped with the standard library

This is true for the Package Manager in executable form.

Post by Paul Moore
Given that David's package manager uses setuptools to do the installs
(and now it appears it uses wxPython for its GUI) that immediately
disqualifies it for inclusion in my view - regardless of its value as
a package.

Yes, It offers the choice to install via setuptools.

As well as PIP.

And it will be extended to Enstaller.

Presently it used pkg_resources to read the list of packages installed
which is part of setuptools. I was told it was the "right" and only way
to read a list of packages. If using this package presents a problem, then
it can be removed and I will replace the functionality with my own code.

If the gui needs to be rewritten in TK this can be accomplished.

I'm in no way pushing any GUI toolkit, and this was the one suggested to
me by many. Redoing to meet the above criteria is achievable.

If there's any other objections, can they be raised now before I
start a rewrite? Thank you.

David

[P.J. Eby]

Post by David Lyon
Presently it used pkg_resources to read the list of packages installed
which is part of setuptools. I was told it was the "right" and only way
to read a list of packages.

"Right" is relative, but right now it is certainly the *only* way to
read a list of installed packages, that's compatible with both
distutils and setuptools-based ways of installing packages (including
of course pip, enstaller, and buildout).

PEP 376 proposes a stdlib replacement for a portion of this
functionality, but the status of whether it's actually going to
support anything other than distutils, pip, and setuptools'
backward-compatibility mode is apparently still up for grabs.

[Stephen J. Turnbull]

Post by David Lyon

Post by Paul Moore
I read this as meaning that David was proposing to ship a built
application (on Windows, bundled up with something like py2exe, I
guess) and any supporting DLLs such as the wxWindows ones would be
bundled in, but the wxPython package would *not* be shipped as part of
the standard library.

That's correct.

-1, then. Python is open source. Anything shipped with the standard
distribution should be buildable with the Pythonic tools in the
standard distribution. Obviously the C compiler and operating system
services are non-Pythonic, and the line is pretty fuzzy, but I would
not want to extend similar consideration to wxPython.

This kind of thing is what ActiveState and the OS distros are for.

If you say this is discriminating against Windows, well, it probably
is, but it should be addressed with a Windows solution, such as a
script to generate MSIs.

[David Lyon]

Post by Georg Brandl

Post by David Lyon
In executable form, the Package Manager does not require wxWidgets
to be installed.
There is no dependency for this to be installed.

What does "in exectuable form" mean?

Compiled with py2exe.

An executable ".exe" file is created under windows.

David

[David Lyon]

Post by Christian Heimes
I'm sorry to inform you that a wxWindows based solution has zero change
to get into the Python standard library ever.

Is that a personal preference or is there a software engineering reason
for this?

I wasn't suggesting including it in the standard library as I like others
know how troublesome it can be.

Post by Christian Heimes
We are not going to add
another GUI toolkit to the core distribution. We might even remove TK
from the core and ship it as a separate package like bsddb3.

So is this a bias against native window applications?

Does the application need to be web based?

or console based?

or TK based... ?

For it to be acceptable..

Thank you

David

[Ben Finney]

Post by d***@preisshare.net
Distutils was once seperate and was then included in the standard python.
So i guess that I am working with the same goal in mind.

I interpret this as expressing your intent to (eventually) have your
application included in standard Python.

Post by d***@preisshare.net

Post by Christian Heimes
I'm sorry to inform you that a wxWindows based solution has zero
change to get into the Python standard library ever.

I wasn't suggesting including it in the standard library as I like
others know how troublesome it can be.

This appears to contradict what you said above.

Post by d***@preisshare.net

Post by Christian Heimes
We are not going to add another GUI toolkit to the core
distribution. We might even remove TK from the core and ship it as a
separate package like bsddb3.

So is this a bias against native window applications?

No, it's a bias against adding things to Python that depend on things
not already in Python.

Are you, or are you not, intending for your application to be in
standard Python?

If that is your intent, I think Christian's answer is valid:
applications, especially ones that depend on third-party widget
libraries, shouldn't get added to Python.

If that is not your intent, then your application shouldn't be mentioned
in standard Python documentation.

[Jean-Paul Calderone]

[snip]
If that is not your intent, then your application shouldn't be mentioned
in standard Python documentation.

Hm. But docutils isn't part of the standard library, and the documentation
refers to it. And the docs link to ActivePython and Enthought's Python
distribution. And they link to things like "Collin Winter’s functional
module" and Django and PyOpenGL and so forth.

I don't think anyone would seriously suggest removing all references to
third-party software from the Python documentation. Perhaps the criterion
that David is looking to have is explained is that people would probably
prefer for his app to get a bit more popular before Python itself starts
pointing people in its direction.

Jean-Paul

[Ben Finney]

Hm. But docutils isn't part of the standard library, and the
documentation refers to it.

Fair enough, because the documentation is generated using Docutils.

And the docs link to ActivePython and Enthought's Python distribution.

I consider those to be exceptions that prove the rule: they are
“standard Python” in a different form.

And they link to things like "Collin Winter’s functional module" and
Django and PyOpenGL and so forth.

I don't know enough about those to comment.

I don't think anyone would seriously suggest removing all references to
third-party software from the Python documentation.

No, and nor did I. I'm suggesting that *adding* such a reference has a
high barrier.

Perhaps the criterion that David is looking to have is explained is
that people would probably prefer for his app to get a bit more
popular before Python itself starts pointing people in its direction.

Right. The process is usually in the following order:

* get the code registered on PyPI

* get a community of users and make the code meet their needs well

* discuss adding some or all of the code to Python, by (in recent years)
raising the topic on ‘python-ideas’

* defend the proposal against all comers to ensure it's actually a good
idea

* await further instructions

[Brett Cannon]

Post by Jean-Paul Calderone

[snip]
If that is not your intent, then your application shouldn't be mentioned
in standard Python documentation.

Hm. But docutils isn't part of the standard library, and the documentation
refers to it.

Why do you think distutils is not part of the standard library? The official
code location is Lib/distutils within the standard library.

-Brett

[Brett Cannon]

Post by Brett Cannon

On Sat, 25 Jul 2009 10:40:52 +1000, Ben Finney <

[snip]
If that is not your intent, then your application shouldn't be mentioned
in standard Python documentation.

Hm. But docutils isn't part of the standard library, and the
documentation
refers to it.

Why do you think distutils is not part of the standard library? The
official code location is Lib/distutils within the standard library.

Oops, I misread the project JP mentioned. Ignore me. =)

-Brett

[Robert Kern]

On Sat, 25 Jul 2009 10:40:52 +1000, Ben Finney
[snip]
If that is not your intent, then your application shouldn't be mentioned
in standard Python documentation.
Hm. But docutils isn't part of the standard library, and the documentation
refers to it.
Why do you think distutils is not part of the standard library? The
official code location is Lib/distutils within the standard library.

He said "docutils", not "distutils".

[David Lyon]

Post by Ben Finney
I interpret this as expressing your intent to (eventually) have your
application included in standard Python.

It's my intention to get a Package Manager included in standard
python - yes.

Post by Ben Finney

Post by David Lyon
I wasn't suggesting including it in the standard library as I like
others know how troublesome it can be.

This appears to contradict what you said above.

Not at all. In source form the pythonpkgmgr requires wx package. In
executable form it does not.

Post by Ben Finney
No, it's a bias against adding things to Python that depend on things
not already in Python.

That implies that nothing new can be added then.

Post by Ben Finney
Are you, or are you not, intending for your application to be in
standard Python?
applications, especially ones that depend on third-party widget
libraries, shouldn't get added to Python.
If that is not your intent, then your application shouldn't be mentioned
in standard Python documentation.

The Python Package Manager can be written to work in console mode.

It can be redone to work with the TK that already ships.

That doesn't present any great problem.

If it was the interests of python users that were foremost, being
able to install packages in a modern way - Then I think there would
be more room to move than this. It's no different than any other
windows application that ships with dll files.

I fully appreciate that changes could be necessary and I'm prepared to
accomodate them.

Not much more I can do than that..

David

[Ben Finney]

Post by David Lyon
Not at all. In source form the pythonpkgmgr requires wx package. In
executable form it does not.

The only way it could be added is in source form; that's essential for
free software like Python. So, if it's not suitable for adding to Python
in source form, it's not suitable for adding to Python.

Post by David Lyon

Post by Ben Finney
No, it's a bias against adding things to Python that depend on things
not already in Python.

That implies that nothing new can be added then.

You omit the important part: adding a new thing to Python *so long as it
doesn't depend on anything outside Python*.

Post by David Lyon
The Python Package Manager can be written to work in console mode.

I think this would be best. The functionality you often discuss around
this tool would be best implemented independently of any UI. It would,
in fact, be best to work with the team performing ongoing active
standardisation of distutils functionality.

[Ben Finney]

The functionality you often discuss around this tool would be best
implemented independently of any UI. It would, in fact, be best to
work with the team performing ongoing active standardisation of
distutils functionality.

Sloppy use of “in fact”. That should be “in my opinion”.

[David Lyon]

Post by Ben Finney
You omit the important part: adding a new thing to Python *so long as it
doesn't depend on anything outside Python*.

I'm signing out on this silly discussion for now....

Any python program is dependant on things "outside" python. For
example an operating system.. a computer... and a user perhaps
for without such it wouldn't be possible to generate the all important
1Di0t errors that we so often have to deal with.

Post by Ben Finney

Post by David Lyon
The Python Package Manager can be written to work in console mode.

I think this would be best.

Haha - I'm glad somebody took this seriously... It was a sort of a joke
comment but it's a serious possibility.

Post by Ben Finney
The functionality you often discuss around
this tool would be best implemented independently of any UI.

It is anyway. That's why doing an entirely different UI isn't any
major issue. I have a class and a possible command line interface
behind the scenes.

Post by Ben Finney
It would, in fact, be best to work with the team performing ongoing
active standardisation of distutils functionality.

I am already doing that.

But there is a bias against windows development and a bias
against native applications. That's fine because I know they
are using python on different platforms.

I'm working on a proposal to make setup.py object oriented
and "modern".

http://wiki.python.org/moin/Distutils/Proposals

So I'm doing as much as I can - really.

David

[Ben Finney]

Post by David Lyon

Post by Ben Finney
You omit the important part: adding a new thing to Python *so long
as it doesn't depend on anything outside Python*.

I'm signing out on this silly discussion for now....
Any python program is dependant on things "outside" python.

I think you know quite well what “depend on” means in this instance,
so this is taking it to silly extremes.

[David Lyon]

Post by Ben Finney
I think you know quite well what “depend on” means in this instance,
so this is taking it to silly extremes.

haha - yes - no offence.

It was just bad humour.

Have a nice weekend

David

[Paul Moore]

Received: from localhost.localdomain (HELO mail.python.org) (127.0.0.1)
by albatross.python.org with SMTP; 25 Jul 2009 11:28:56 +0200
X-policyd-weight: using cached result; rate: -8.4
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156])
by mail.python.org (Postfix) with ESMTP
for <python-***@python.org>; Sat, 25 Jul 2009 11:28:56 +0200 (CEST)
Received: by fg-out-1718.google.com with SMTP id l26so613202fgb.10
for <python-***@python.org>; Sat, 25 Jul 2009 02:28:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=sfM9cLlakJn8/2XhjOTvPPm2gl6AA/F2sDwwd/hhNUY=;
b=wAGDYLHtvWG4+dS6J3Dy7x62E1ra77EAHZFyqSBQdrDt6ETKAyn9LR8Ho+NKvwaB19
g8yZoVMGNZva6rNwisR4TZQGnTLBDj4BbExPxEqXqfz/6NlkT04LygQOWQlunOsSKo/1
kwtzMjVvhX4gavOjzT8FZimfvhLgd3SXnYbn4DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type:content-transfer-encoding;
b=t7COcNoHSYb5Gj1PTFjCbEaRm7MhxdMb/vFaX/n++OwRQE/c5B8ay9KXo3MFbYEPix
FIKJm3cyfnjjgvXnukrc3r+iUIfkmWMdStIeh+/nGCFVYelQoGFdxsiNV3b1iv7DX00x
3S/afGs3kJySw4F3ST7OkoyJeQw0BKj1Xtf90Received: by 10.86.94.11 with SMTP id r11mr544705fgb.62.1248514131694; Sat, 25
Jul 2009 02:28:51 -0700 (PDT)
In-Reply-To: <***@preisshare.net>
X-BeenThere: python-***@python.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Python core developers <python-dev.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/options/python-dev>,
<mailto:python-dev-***@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-dev>
List-Post: <mailto:python-***@python.org>
List-Help: <mailto:python-dev-***@python.org?subject=help>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-dev>,
<mailto:python-dev-***@python.org?subject=subscribe>
Sender: python-dev-bounces+python-python-dev=***@python.org
Errors-To: python-dev-bounces+python-python-dev=***@python.org
Archived-At: <http://permalink.gmane.org/gmane.comp.python.devel/105615>

Post by David Lyon

Post by Ben Finney
It would, in fact, be best to work with the team performing ongoing
active standardisation of distutils functionality.

I am already doing that.
But there is a bias against windows development and a bias
against native applications. That's fine because I know they
are using python on different platforms.

??? I see no bias as you describe in the distutils enhancement work.
Everything so far has been carefully platform-neutral (ie, *not*
biased against Windows, but equally not biased against other operating
systems).

Native applications are by definition not platform neutral. How does
your proposal help Linux users? Mac OS? Solaris?

I think you are seeing bias against Windows where non exists. What
*does* exist is
- A concern that tools work for everyone, regardless of OS
- A limited number of people willing to explain Windows issues so that
they get considered

Post by David Lyon
I'm working on a proposal to make setup.py object oriented
and  "modern".
http://wiki.python.org/moin/Distutils/Proposals

And that looks interesting, and potentially useful (although perhaps
more radical than will end up being possible).

Post by David Lyon
So I'm doing as much as I can - really.

If your concern is to make things easier for Windows users, then your
application is worthwhile, but it should probably remain an external
project. If it gets overwhelming support, maybe providing a
standardised version with a simplified UI in the core would be an
option. How many users do you have currently?

Paul.

PS Does your application work with the large existing base of
bdist_msi and bdist_wininst installers? Unless it will manage pywin32,
cx_Oracle, PIL, wxPython, pyQT, pygame, numpy etc (all of which are
available in binary form but not as eggs as far as I know, and have
too complex a set of dependencies for me to build locally) it's
useless to me.

[David Lyon]

Post by Paul Moore
??? I see no bias as you describe in the distutils enhancement work.

ok

Post by Paul Moore
Native applications are by definition not platform neutral. How does
your proposal help Linux users? Mac OS? Solaris?

I'm doing a Linux/Solaris version. But I find issues every day that
must be addressed.

Post by Paul Moore
If your concern is to make things easier for Windows users, then your
application is worthwhile, but it should probably remain an external
project. If it gets overwhelming support, maybe providing a
standardised version with a simplified UI in the core would be an
option.

That sounds ok.

Post by Paul Moore
How many users do you have currently?

Approx 250 downloads this (first) month for the windows version. I need
to extend coverage to Linux and the Mac. Given that I'm relatively new
to all this there's a learning curve.

But so far so good.

David

[Terry Reedy]

Post by David Lyon

Post by Ben Finney

Post by David Lyon
The Python Package Manager can be written to work in console mode.

I think this would be best.

Haha - I'm glad somebody took this seriously... It was a sort of a joke
comment but it's a serious possibility.

I took it seriously too ;-). It seems to me that you project can have at
least 3 components. 1) the core library module, which might or might not
be targeted at eventual stdlib inclusion. 2) a small console driver
script. 3) one or more GUI scripts. A TK version would be good from my
viewpoint as it does not require download and installation of any other
binaries. Removal of TK from the Windows distribution will be extremely
contentious if seriously proposed, so it could not happen for a while.

tjr

[David Lyon]

Received: from localhost.localdomain (HELO mail.python.org) (127.0.0.1)
by albatross.python.org with SMTP; 26 Jul 2009 03:42:54 +0200
X-policyd-weight: using cached result; rate: -7.6
Received: from syd-srv02.ezyreg.com (syd-srv02.ezyreg.com [117.58.251.3])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mail.python.org (Postfix) with ESMTPS
for <python-***@python.org>; Sun, 26 Jul 2009 03:42:53 +0200 (CEST)
Received: from localhost ([127.0.0.1] helo=syd-srv02.ezyreg.com)
by syd-srv02.ezyreg.com with esmtpa (Exim 4.69)
(envelope-from <***@preisshare.net>)
id 1MUshU-0004St-02; Sat, 25 Jul 2009 21:38:56 -0400
In-Reply-To: <h4fcup$tic$***@ger.gmane.org>
X-Sender: ***@preisshare.net
User-Agent: RoundCube Webmail/0.2
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - syd-srv02.ezyreg.com
X-AntiAbuse: Original Domain - python.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - preisshare.net
X-Source:
X-Source-Args:
X-Source-Dir:
X-BeenThere: python-***@python.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Python core developers <python-dev.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/options/python-dev>,
<mailto:python-dev-***@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-dev>
List-Post: <mailto:python-***@python.org>
List-Help: <mailto:python-dev-***@python.org?subject=help>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-dev>,
<mailto:python-dev-***@python.org?subject=subscribe>
Sender: python-dev-bounces+python-python-dev=***@python.org
Errors-To: python-dev-bounces+python-python-dev=***@python.org
Archived-At: <http://permalink.gmane.org/gmane.comp.python.devel/105638>

Post by Terry Reedy

Post by David Lyon

Post by Ben Finney

Post by David Lyon
The Python Package Manager can be written to work in console mode.

I think this would be best.

Haha - I'm glad somebody took this seriously... It was a sort of a joke
comment but it's a serious possibility.

I took it seriously too ;-). It seems to me that you project can have at
least 3 components.

It's logical and plausible.

Post by Terry Reedy
1) the core library module, which might or might not be targeted at

eventual stdlib inclusion.

I'm sure they'll fix distutils someday, and if they do, then I'll use
that.

Post by Terry Reedy
2) a small console driver script. 3) one or more GUI scripts.

It's possible. I'll give it serious consideration.

Post by Terry Reedy
A TK version would be good from my
viewpoint as it does not require download and installation of any other
binaries.

Sure. Who cares if it's not as slick as something else. I'll try
when I have time.

David

[Martin v. Löwis]

Post by David Lyon
It's my intention to get a Package Manager included in standard
python - yes.

In addition to the other constraints you'll have to meet for this
to happen, you also have to wait a rather long time (several years)
before inclusion becomes possible. This time is necessary for the
community to accept your tool, and evaluate it. Ideally, the request
for inclusion should not come from you, but from your users.

Post by David Lyon
Not at all. In source form the pythonpkgmgr requires wx package. In
executable form it does not.

If we include it, we *only* include it in source form. Inclusion
in executable form is not acceptable. We also require that it works on
all major systems, not just windows.

Post by David Lyon

Post by Ben Finney
No, it's a bias against adding things to Python that depend on things
not already in Python.

That implies that nothing new can be added then.

No. It implies that any addition could only depend on Python (and
OS API) - so things *can* be added. For example, setuptools could
be added by this principle. OTOH, if your tool depends on setuptools,
you'll have to wait for setuptools to get included before inclusion
of your tool can be considered.

Regards,
Martin

[David Lyon]

Post by Martin v. Löwis

Post by David Lyon
It's my intention to get a Package Manager included in standard
python - yes.

In addition to the other constraints you'll have to meet for this
to happen, you also have to wait a rather long time (several years)
before inclusion becomes possible. This time is necessary for the
community to accept your tool, and evaluate it. Ideally, the request
for inclusion should not come from you, but from your users.

Yes. But users have been asking for a tool and complaining loudly
about the lack of such a tool. I know you're an extremely competent
and those emails you perphaps floss over. But the pleas are many and
when we compare python to other languages, python rates towards at the
low end of the spectrum its third party-package management facilities.

You can't seriously expect users to wait for years for an integrated
package management tool. Especially on Windows - that's cruel :-)

To date, there just hasn't been any movement on the building of
such a tool due to whatever reasons.

A Package Manager isn't a frivolous "nice-to-have" tool. It's
essential for a new user.

(if you want I can sift the last twelve months worth of ML
archives and report on how many times easier package management
has been asked for. And how difficult people are finding it)

Post by Martin v. Löwis
No. It implies that any addition could only depend on Python (and
OS API) - so things *can* be added. For example, setuptools could
be added by this principle. OTOH, if your tool depends on setuptools,
you'll have to wait for setuptools to get included before inclusion
of your tool can be considered.

Let's get precise. It doesn't "depend" on setuptools. But it will
install setuptools if the user requests to use setuptools/easy_install.

So we should only be back to the lack of a TK interface and the fact that
the Package Manager Project is a new project, and needs to be working
properly on more platforms.

Thanks for your email. I appreciate the feedback, from everyone.

Take care.

David

[Martin v. Löwis]

Post by David Lyon
You can't seriously expect users to wait for years for an integrated
package management tool. Especially on Windows - that's cruel :-)

Hmm. I'm -0 on providing a tool whose only purpose is to download
files from a web server. I always use a web browser for that...

Post by David Lyon
A Package Manager isn't a frivolous "nice-to-have" tool. It's
essential for a new user.

Hmm. I would expect that a new user is faced with the challenge
of finding out what packages to install more so than with actually
installing them. If they read examples, they will see import
statements, and then they have to find out how to make those work.
Does your tool help with that?

When the user is not so new anymore, I seriously doubt that they
still ask for a package management tool - except perhaps for
dependencies, and here they use easy_install.

Regards,
Martin

[David Lyon]

Post by Martin v. Löwis
Hmm. I'm -0 on providing a tool whose only purpose is to download
files from a web server. I always use a web browser for that...

It does a lot more than that. Firstly it shows what packages you
already have installed and lets you manage them. Namely, deinstall,
(manually) upgrade, view documentation and examples.

In any case, even if it were only a tool to download packages
it's still consistant with modern appliance design (mobile phones,
programming languages, dedicated hardware) to have an internal
application where a user can pretty easily download "checked"
apps to their device/system.

Nobody gives people just a browser to do that... and tell them
"go browse". It isn't being done like that - except in python.

Post by Martin v. Löwis
Hmm. I would expect that a new user is faced with the challenge
of finding out what packages to install more so than with actually
installing them.

Yes. That's exactly the point. You're 100% right.

That's why the pythonpkgmgr provides a useful search capability
for pypi packages. It's faster and more natural to use a native
app than do it all in the browser. That's true in Perl (cpan) as
in Python and I'm honestly saying that I can't find any noteable
faults in pypi the way I find it.

Post by Martin v. Löwis
If they read examples, they will see import
statements, and then they have to find out how to make those work.
Does your tool help with that?

Yes. It will open the website or homepage to the project/package
in question. And find any documentation that might be stored in
the package directory.

If you only have "import interbasedb" it's a complicated process
for a new user to located the home page or project documentation
without pythonpkgmgr.

Using pythonpkgmgr, they look on their list of installed packages,
find the "interbasedb" or whatever module, and can get quick
access to the pypi page or the package homepage. It's much easier.

Much faster.. especially if the new user doesn't know the
internals of package storage, pypi and the like.

Post by Martin v. Löwis
When the user is not so new anymore, I seriously doubt that they
still ask for a package management tool - except perhaps for
dependencies, and here they use easy_install.

Well, that might be one use-case.

It's true that many python programmers will just want to stick to
their own "known" packages.

However, this tool aids people with more curiosity. Because users can
so easily (and safely) install and deinstall anything.

It's only a click to install a package, and another to deinstall.

At the moment, pythonpkgmgr doesn't handle dependencies except that
which is provided internally by easy_install/pip.

I'm hoping to change this as my experience and understanding grows.

David

[Martin v. Löwis]

Received: from localhost.localdomain (HELO mail.python.org) (127.0.0.1)
by albatross.python.org with SMTP; 26 Jul 2009 19:31:47 +0200
X-policyd-weight: using cached result; rate: -8.5
Received: from smtprelay11.ispgateway.de (smtprelay11.ispgateway.de
[80.67.31.34]) by mail.python.org (Postfix) with ESMTP
for <python-***@python.org>; Sun, 26 Jul 2009 19:31:47 +0200 (CEST)
Received: from [77.131.207.241] (helo=[192.168.178.20])
by smtprelay11.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256)
(Exim 4.68) (envelope-from <***@v.loewis.de>)
id 1MV7ZV-0000B0-AB; Sun, 26 Jul 2009 19:31:41 +0200
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
In-Reply-To: <***@preisshare.net>
X-Enigmail-Version: 0.96.0
X-Df-Sender: 544451
X-BeenThere: python-***@python.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Python core developers <python-dev.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/options/python-dev>,
<mailto:python-dev-***@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-dev>
List-Post: <mailto:python-***@python.org>
List-Help: <mailto:python-dev-***@python.org?subject=help>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-dev>,
<mailto:python-dev-***@python.org?subject=subscribe>
Sender: python-dev-bounces+python-python-dev=***@python.org
Errors-To: python-dev-bounces+python-python-dev=***@python.org
Archived-At: <http://permalink.gmane.org/gmane.comp.python.devel/105646>

Post by David Lyon

Post by Martin v. Löwis
If they read examples, they will see import
statements, and then they have to find out how to make those work.
Does your tool help with that?

Yes. It will open the website or homepage to the project/package
in question.

How does it know the project in question?

Post by David Lyon
Using pythonpkgmgr, they look on their list of installed packages,
find the "interbasedb" or whatever module, and can get quick
access to the pypi page or the package homepage. It's much easier.

How do they find interbasedb in the list of installed packages if
they haven't installed interbasedb yet?

Regards,
Martin

[David Lyon]

Post by Martin v. Löwis

Post by David Lyon

Post by Martin v. Löwis
If they read examples, they will see import
statements, and then they have to find out how to make those work.
Does your tool help with that?

Yes. It will open the website or homepage to the project/package
in question.

How does it know the project in question?

Because it is either in the pypi search results or list of installed
packages.

Post by Martin v. Löwis
How do they find interbasedb in the list of installed packages if
they haven't installed interbasedb yet?

They'd already installed it. But perphaps through a .exe installer.


David

[Steven D'Aprano]

Post by David Lyon

Post by Martin v. Löwis
In addition to the other constraints you'll have to meet for this
to happen, you also have to wait a rather long time (several years)
before inclusion becomes possible. This time is necessary for the
community to accept your tool, and evaluate it. Ideally, the
request for inclusion should not come from you, but from your
users.

Yes. But users have been asking for a tool and complaining loudly
about the lack of such a tool. I know you're an extremely competent
and those emails you perphaps floss over. But the pleas are many and
when we compare python to other languages, python rates towards at
the low end of the spectrum its third party-package management
facilities.
You can't seriously expect users to wait for years for an integrated
package management tool. Especially on Windows - that's cruel :-)

Life is cruel and hard. Anyone who tells you different is selling
something.

Nobody is saying that users have to wait for years for such a tool. They
can download it from wherever you host it. But you shouldn't expect the
Python dev team to accept an unproven tool into the official library
before demonstrating both the need and the solution. (Just because
users say they want something, doesn't mean they'll actually use the
tool you provide -- perhaps they don't know what they really need, and
perhaps your tool doesn't match their needs.)

I'm a user, and personally I don't want Yet Another Integrated Package
Management Tool. What I really want is the ability to install Python
packages using the PM tool I already use, namely yum. (And I'd like a
pony.) Failing that, I want the Python standard library to be stable
and reliable. With the greatest of respect, fast-tracking unproven
tools into the library based on the author's say-so is the first step
to instability and unreliability.

Putting your software on the Cheeseshop, and making regular
announcements to the Python community (e.g. on comp.lang.python) will
be a good way to publicise the tool, and if does meet a need, people
will use it, and then, if it's good enough and popular enough and
supported, it may be blessed by inclusion in the standard library.

Although I'm not a Windows user, let me say thank you for your efforts
on behalf of Python users. Good luck!

[Nick Coghlan]

Post by Steven D'Aprano
I'm a user, and personally I don't want Yet Another Integrated Package
Management Tool. What I really want is the ability to install Python
packages using the PM tool I already use, namely yum. (And I'd like a
pony.)

Picking up on this point... out of curiousity, I threw a couple of
package names at "apt-get -s" on my main (Ubuntu 8.04) PC to see what
worked.

The first two names I tried (numpy, scipy) didn't work, but the next
four (python-numpy, python-scipy, python-django, python-turbogears) all
had hits. Because Turbo Gears incorporates so many other projects, the
simulated run at installing it provided a nice overview of a variety of
other Python packages in the Ubuntu repositories as well.

No doubt a search in Adept would reveal a whole lot more "python-*"
packages that are just a few clicks away for me.

</tangent>

Cheers,
Nick.

[David Lyon]

Post by Steven D'Aprano
But you shouldn't expect the
Python dev team to accept an unproven tool into the official library
before demonstrating both the need and the solution.

Of course... that's why I started off by asking what the process is.

I am accepting that the current status of pythonpkgmgr is "unproven" so
it will need some time for things to run their course.

Post by Steven D'Aprano
(Just because
users say they want something, doesn't mean they'll actually use the
tool you provide -- perhaps they don't know what they really need, and
perhaps your tool doesn't match their needs.)

Conversely, the process of satisfying needs is to discuss them. And
people have been ever so helpful in that regard.

Post by Steven D'Aprano
I'm a user, and personally I don't want Yet Another Integrated Package
Management Tool. What I really want is the ability to install Python
packages using the PM tool I already use, namely yum.

ok - but no alternative to that is available on windows.

pythonpkgmgr is not so different to that. And the idea behind it is
to bring consistancy in package management across the different
platforms.

It does have configuration that are specific to python, and will
continue to do so. Like being able to specify where one wants the
package installed.

Post by Steven D'Aprano
Putting your software on the Cheeseshop, and making regular
announcements to the Python community (e.g. on comp.lang.python) will
be a good way to publicise the tool, and if does meet a need, people
will use it, and then, if it's good enough and popular enough and
supported, it may be blessed by inclusion in the standard library.

Thanks very much. Take care.

David

[Michael Foord]

Post by David Lyon

Post by Steven D'Aprano
But you shouldn't expect the
Python dev team to accept an unproven tool into the official library
before demonstrating both the need and the solution.

Of course... that's why I started off by asking what the process is.
I am accepting that the current status of pythonpkgmgr is "unproven" so
it will need some time for things to run their course.

It would be great to have a decent visual package manager for Python.
It needs to be built on top of the work that Tarek is doing with
distutils (and be compatible with his Distribute fork of setuptools) and
it also needs to be established.

The good news is that there is time for both... Aren't there other tools
that have similar goals? PyPI browser, Yolk etc

It is a shame that it needs to be built on Tk if it is to stand a chance
of ever being included in the standard library - but with the right
expertise it is *possible* to create decent looking UIs with Tk.

Michael

Post by David Lyon

Post by Steven D'Aprano
(Just because
users say they want something, doesn't mean they'll actually use the
tool you provide -- perhaps they don't know what they really need, and
perhaps your tool doesn't match their needs.)

Conversely, the process of satisfying needs is to discuss them. And
people have been ever so helpful in that regard.

Post by Steven D'Aprano
I'm a user, and personally I don't want Yet Another Integrated Package
Management Tool. What I really want is the ability to install Python
packages using the PM tool I already use, namely yum.

ok - but no alternative to that is available on windows.
pythonpkgmgr is not so different to that. And the idea behind it is
to bring consistancy in package management across the different
platforms.
It does have configuration that are specific to python, and will
continue to do so. Like being able to specify where one wants the
package installed.

Post by Steven D'Aprano
Putting your software on the Cheeseshop, and making regular
announcements to the Python community (e.g. on comp.lang.python) will
be a good way to publicise the tool, and if does meet a need, people
will use it, and then, if it's good enough and popular enough and
supported, it may be blessed by inclusion in the standard library.

Thanks very much. Take care.
David
_______________________________________________
Python-Dev mailing list
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk

[David Lyon]

On Sun, 26 Jul 2009 17:23:59 +0100, Michael Foord

Post by Michael Foord
It would be great to have a decent visual package manager for Python.

Hopefully one day we'll have one - haha

Post by Michael Foord
It needs to be built on top of the work that Tarek is doing with
distutils (and be compatible with his Distribute fork of setuptools) and
it also needs to be established.

I'm planning to support it - like I do for setuptools and pip

Post by Michael Foord
The good news is that there is time for both... Aren't there other tools
that have similar goals? PyPI browser, Yolk etc

The fact is that there's way more glamorous things to work on
than a package manager. Nobody has written a package manager for
python imho simply because there's so many more fun things to
do with python than that...

Post by Michael Foord
It is a shame that it needs to be built on Tk if it is to stand a chance
of ever being included in the standard library - but with the right
expertise it is *possible* to create decent looking UIs with Tk.

I'm working on a TK version.. yes.. a TK version is better than nothing
and the differences between a TK and a WX version is really only pretty
minor. To me, wx is ancient... and tk is simply prehistoric.

mr.new-to-python developer wouldn't really cares too much either I
would suspect. All they want is to be up and running quickly.

My only point is that Windows ain't no embedded system. It's not
short on memory or disk space. If a package manager is 5 megabytes
extra say, with it's libraries.. what's the extra download time on
that ? compared to three days+ stuffing around trying to find out
how to install packages for a new user.

If the source needs to go in too.. that's a few kilobytes.

That's like 57 extra bytes to an old-timer... I know.. it's
such a sacrifice.. and we're all working on 300 baud... :-)

David

[David Cournapeau]

Post by David Lyon
My only point is that Windows ain't no embedded system. It's not
short on memory or disk space. If a package manager is 5 megabytes
extra say, with it's libraries.. what's the extra download time on
that ? compared to three days+ stuffing around trying to find out
how to install packages for a new user.

The problem is not so much the size by itself that more code means
more maintenance burden for python developers. Including new code
means it has to work everywhere where python works currently, and that
other people can understand/support the related code. Adding code to a
project is far from free from python maintainers POV.

cheers,

David

[David Lyon]

Post by David Cournapeau

Post by David Lyon
My only point is that Windows ain't no embedded system. It's not
short on memory or disk space. If a package manager is 5 megabytes
extra say, with it's libraries.. what's the extra download time on
that ? compared to three days+ stuffing around trying to find out
how to install packages for a new user.

The problem is not so much the size by itself that more code means
more maintenance burden for python developers. Including new code
means it has to work everywhere where python works currently, and that
other people can understand/support the related code. Adding code to a
project is far from free from python maintainers POV.

Well I concede that you might have a point.

And I know there have been some issues in the past with package
management in python and people being able to understand other
peoples code.

In this specific case, I don't think you'll find the same problems.

pythonpkgmgr is not an entirely self inclusive project. It leverages
on setuptools and pip. I want to extend it to enstall. If there is
any preference towards setuptools - it's only by test-time availability.

In windows, it's built with py2exe. There are some supporting
.dll files that need to go with it from wxpython. They're both really
mainstream python(windows) toolkits.

Everything in pythonpkgmgr is transperant - and was designed to
be. Otherwise there's no point.

If any developers want to join the project with 'commit' privaleges
on the source, I'll make sure it will happen.

If not.. I'm very happy just continuing on with my own merry way...

:-)

David

[Martin v. Löwis]

Received: from localhost.localdomain (HELO mail.python.org) (127.0.0.1)
by albatross.python.org with SMTP; 26 Jul 2009 19:33:44 +0200
X-policyd-weight: NOT_IN_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5
NOT_IN_BL_NJABL=-1.5 CL_IP_EQ_HELO_IP=-2 (check from: .loewis.
- helo: .smtprelay04.ispgateway. - helo-domain: .ispgateway.)
FROM/MX_MATCHES_HELO(DOMAIN)=-2; rate: -8.5
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de
[80.67.18.16]) by mail.python.org (Postfix) with ESMTP
for <python-***@python.org>; Sun, 26 Jul 2009 19:33:44 +0200 (CEST)
Received: from [77.131.207.241] (helo=[192.168.178.20])
by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256)
(Exim 4.68) (envelope-from <***@v.loewis.de>)
id 1MV7aE-0008RA-Bf; Sun, 26 Jul 2009 19:32:26 +0200
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
In-Reply-To: <***@preisshare.net>
X-Enigmail-Version: 0.96.0
X-Df-Sender: 544451
X-BeenThere: python-***@python.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Python core developers <python-dev.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/options/python-dev>,
<mailto:python-dev-***@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-dev>
List-Post: <mailto:python-***@python.org>
List-Help: <mailto:python-dev-***@python.org?subject=help>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-dev>,
<mailto:python-dev-***@python.org?subject=subscribe>
Sender: python-dev-bounces+python-python-dev=***@python.org
Errors-To: python-dev-bounces+python-python-dev=***@python.org
Archived-At: <http://permalink.gmane.org/gmane.comp.python.devel/105647>

Post by David Lyon

Post by Steven D'Aprano
I'm a user, and personally I don't want Yet Another Integrated Package
Management Tool. What I really want is the ability to install Python
packages using the PM tool I already use, namely yum.

ok - but no alternative to that is available on windows.

For removal of packages, an alternative *is* available: APR.

Post by David Lyon
pythonpkgmgr is not so different to that. And the idea behind it is
to bring consistancy in package management across the different
platforms.

At the cost of being inconsistent within a platform.

Regards,
Martin

[Stephen J. Turnbull]

Post by Martin v. Löwis

Post by David Lyon
pythonpkgmgr is not so different to that. And the idea behind it is
to bring consistancy in package management across the different
platforms.

At the cost of being inconsistent within a platform.

Indeed, and that seems to be one of the really big sticking points in
all efforts to improve Python's package management: the conflict
between user goals ("something that works for me without any effort[1] on
my part") and sysadmin goals ("something that works and plays nicely
with the rest of the system").

pythonpkgmgr seems entirely oblivious to the latter issue, and not
particularly compatible with the way package management works in *nix
OSS distros (including Linux distros, but also *BSD, MacPorts, and
Fink). I think that will probably kill uptake on those platforms --
could be wrong, but caution is suggested.

BTW, I think Tarek's efforts strike a good balance between these
goals, and the whole PEP 376 process has demonstrated how difficult it
is to serve these two masters at the same time.

Footnotes:
[1] I'm a professional economist: in my lexicon, effort minimization
is a positive goal, not laziness. Zero is just an extreme case.

[David Lyon]

On Mon, 27 Jul 2009 11:18:25 +0900, "Stephen J. Turnbull"

Post by Stephen J. Turnbull
[1] on
my part") and sysadmin goals ("something that works and plays nicely
with the rest of the system").
pythonpkgmgr seems entirely oblivious to the latter issue, and not
particularly compatible with the way package management works in *nix
OSS distros (including Linux distros, but also *BSD, MacPorts, and
Fink).

Well I'm a sysadmin on linux in my day job.

I'm entirely wondering what you mean by that ? I'm oblivious how?

What can a developer mode project, like pythonpkgmgr possibly do
except to make it easier to manage local package space?

A developer shouldn't need to do sudo every time they want
to put or try some python package from pypi. imho that's
wrong and I'm helping to reduce that need.

If the sysadmin puts a package in (/usr/lib/pythonX.Y/site-packages)
via the O/S package manager (ie synaptics/yum/apt) then that
should stick over what a developer is doing.

But the developer should be able to stick their own packages
in their own local space.

Correct me if my assertion is wrong.

David

[Stephen J. Turnbull]

Post by David Lyon
On Mon, 27 Jul 2009 11:18:25 +0900, "Stephen J. Turnbull"

Post by Stephen J. Turnbull
[1] on
my part") and sysadmin goals ("something that works and plays nicely
with the rest of the system").
pythonpkgmgr seems entirely oblivious to the latter issue, and not
particularly compatible with the way package management works in *nix
OSS distros (including Linux distros, but also *BSD, MacPorts, and
Fink).

Well I'm a sysadmin on linux in my day job.
I'm entirely wondering what you mean by that ? I'm oblivious how?

Not you; pythonpkgmgr. You've said nothing about how pythonpkgmgr is
supposed to deal with multiple installed versions of Python or
individual modules, or how it helps if you need a custom version of a
module, etc., or how it can help the developer's "local" modules
cooperate/not interfere with system versions, etc.

Post by David Lyon
What can a developer mode project, like pythonpkgmgr possibly do
except to make it easier to manage local package space?

Pave the road to DLL Hell with good intentions, of course.

Post by David Lyon
A developer shouldn't need to do sudo every time they want
to put or try some python package from pypi.

I don't remember *ever* sudo-ing to try a package from pypi.

Post by David Lyon
If the sysadmin puts a package in (/usr/lib/pythonX.Y/site-packages)
via the O/S package manager (ie synaptics/yum/apt) then that
should stick over what a developer is doing.

But I disagree about that, too. The last thing I want is to have my
in-development environment hosed by system upgrades or installations.
Eventually I want to deal with that for deployment, but in the early
stages one can make faster progress on demos or initial target
platforms by sticking to particular versions of prerequisite libraries.

Post by David Lyon
But the developer should be able to stick their own packages
in their own local space.
Correct me if my assertion is wrong.

"Should", yes. But your assertion is incomplete IME: the developer
*is* able to install packages in their own local space *without*
sudo-ing.

I just don't understand what problem you're claiming to solve. The
problem of managing local package space is in some sense solved by
virtualenv, but you haven't mentioned that at all. Is pythonpkgmgr an
alternative? A complement? to virtualenv or zc.buildout?

[David Lyon]

On Mon, 27 Jul 2009 20:12:54 +0900, "Stephen J. Turnbull"

Post by Stephen J. Turnbull
Not you; pythonpkgmgr. You've said nothing about how pythonpkgmgr is
supposed to deal with multiple installed versions of Python

Under windows it can deal with multiple versions of python. You just
go to options and select which version of python you wish to manage.

It's as simple as that.

Post by Stephen J. Turnbull
or how it helps if you need a custom version of a
module, etc., or how it can help the developer's "local" modules
cooperate/not interfere with system versions, etc.

It manages local developer modules for python 2.6+.

As for checks, it doesn't have so many at present. But it makes
it a lot easier to see what you have installed. So if something
needs to be removed and reinstalled - it can do that.

Post by Stephen J. Turnbull
Pave the road to DLL Hell with good intentions, of course.

Well - there's plenty of that

Post by Stephen J. Turnbull

Post by David Lyon
A developer shouldn't need to do sudo every time they want
to put or try some python package from pypi.

I don't remember *ever* sudo-ing to try a package from pypi.

ok. But if you were using an O/S level package manager you
would have to enter a su password to start the tool. Because
that is needed to load packages into /usr/lib/pythonX.y

Post by Stephen J. Turnbull
I just don't understand what problem you're claiming to solve.

Making it simpler for new users to find and install packages
from pypi. And manage the existing packages that are installed
on their machine.

Post by Stephen J. Turnbull
The
problem of managing local package space is in some sense solved by
virtualenv, but you haven't mentioned that at all.

I never heard of it till a few months ago. To my knowledge it
doesn't offer a gui. I'm told it's good for certain things and
I believe it.

My problem was installing packages on windows boxes, not in
the development.

Post by Stephen J. Turnbull
Is pythonpkgmgr an
alternative? A complement? to virtualenv or zc.buildout?

pythonpkgmgr is aimed at featherweight users. It could be
highly complementory to both virtualenv or zc.buildout at
some stage if it were customised to work with those.

For example, it could work with virtualenv by having a
a drop down list of the different 'environments'. I don't
know how to do it right now - but I'm hoping I can figure
it out sometime.

With zc.buildout, there's no reason why it couldn't generate
a package list in that format, or do an import from a
manifest. pythonpkgmgr already can generate a list of
local packages as a manifest - but not in the zc.buildout
format. I'm sure in the future - I'll figure that one out
as well.

David

[Stephen J. Turnbull]

Post by David Lyon
It manages local developer modules for python 2.6+.
pythonpkgmgr is aimed at featherweight users.

You were talking about "developers", but now they're "featherweight
users"? I'm sorry, but the more you post, the less I like the idea of
including it with Python. Please do develop it, do post it to pypi,
and do discuss it on python-list. I'm sure there is an audience for
it, not only for Windows users but for the more GUI-oriented POSIX-
based platforms as well.

But I really don't think that python-dev is the appropriate place any
more.

[David Lyon]

Post by Martin v. Löwis

Post by David Lyon
pythonpkgmgr is not so different to that. And the idea behind it is
to bring consistancy in package management across the different
platforms.

At the cost of being inconsistent within a platform.

It has the most generic of user interfaces.

On Windows, a command line interface is the most out-of-place thing
anybody could ask for.

19/20 kids these days wouldn't even know what a command line interface
is until you show them.

The first thing that they would look for is a GUI tool in the Python X.Y
programs menu...

So I respectfully say that there couldn't be anything less true than
the assertion that a GUI package manager is inconsistent within a
modern GUI desktop environment.

David

[Martin v. Löwis]

Post by David Lyon

Post by Martin v. Löwis

Post by David Lyon
pythonpkgmgr is not so different to that. And the idea behind it is
to bring consistancy in package management across the different
platforms.

At the cost of being inconsistent within a platform.

It has the most generic of user interfaces.

[...]

Post by David Lyon
So I respectfully say that there couldn't be anything less true than
the assertion that a GUI package manager is inconsistent within a
modern GUI desktop environment.

That's not my concern - I'm not worried about how it looks, but what
it does. If it "manages packages", I would expect it to manage them
the same way as the native package manager does, but alas, it doesn't
(IIUC). So there are now two incompatible ways to install a package:
either with the native manager, or with pythonpkgmgr. If you install
them one way, and try to remove them the other way, you lose.

Regards,
Martin

[David Lyon]

Post by Martin v. Löwis
either with the native manager, or with pythonpkgmgr. If you install
them one way, and try to remove them the other way, you lose.

pythonpkgmgr is only a thin wrapper for easy_install/pip.

If there is a problem, then it is already a pre-existing problem
that is not of my doing.

It's certainly true that if a python package is installed with a
windows installer or as a .deb/.rpm, then that package should be
uninstalled using the appropriate and corresponding tool.

The same is true if the package was installed with either pip
or easy_install.

All I can do is put it in my tracker as a bug and deal with it
later when I have time.

Good point

David

[Martin v. Löwis]

Post by David Lyon

Post by Martin v. Löwis
either with the native manager, or with pythonpkgmgr. If you install
them one way, and try to remove them the other way, you lose.

pythonpkgmgr is only a thin wrapper for easy_install/pip.
If there is a problem, then it is already a pre-existing problem
that is not of my doing.

Yes, eggs have the same problem. That's one of the reasons they
don't get integrated into Python.

Regards,
Martin

[David Lyon]

Post by Martin v. Löwis
Yes, eggs have the same problem. That's one of the reasons they
don't get integrated into Python.

Yes but egg_info is included in python...

and the egg is not....

Hence, what goes in and what doesn't isn't always that rational. I'm
just accepting that for the moment.

David

[Paul Moore]

Post by David Lyon

Post by Martin v. Löwis
Yes, eggs have the same problem. That's one of the reasons they
don't get integrated into Python.

Yes but egg_info is included in python...
and the egg is not....
Hence, what goes in and what doesn't isn't always that rational. I'm
just accepting that for the moment.

egg_info data is in to allow "standard" (setup.py install and hence OS
package manager managed) packages to provide metadata in a
discoverable way. Using a format that is (reasonably) compatible with
setuptools is simply a matter of co-operating with existing de facto
standards.

Eggs themselves (as a distribution format) are just zip files with a
funny extension, and as such are supported by Python.

The infrastructure and philosophy around eggs (easy_install, the
various .pth file manipulations, multi-version installs, etc) are
supported by Python (in the trivial sense that they are possible) but
are not "blessed" by standard library inclusion, precisely because of
the issues being mentioned here.

Your package manager has the same issues as the egg infrastructure
(lack of integration with system package managers being the biggest
one) and so is not suitable for the standard library in precisely the
same way.

Paul.

[David Lyon]

Post by Paul Moore
egg_info data is in to allow "standard" (setup.py install and hence OS
package manager managed) packages to provide metadata in a
discoverable way. Using a format that is (reasonably) compatible with
setuptools is simply a matter of co-operating with existing de facto
standards.
Eggs themselves (as a distribution format) are just zip files with a
funny extension, and as such are supported by Python.

ok - I get it.....

It's all one big monty python comedy thing where things are quirky
and inconsistent - there's little continuety from one scene to the
next but you have to stop sometimes and have a laugh... because
to word quote from you - "funny"

Your whole email whilst perphaps technically correct is terribly
difficult for a software engineering person to follow.

Monty python was only meant to be a funny film for entertainment,
not a philosophy for building software from....

Why we can have the egg_info without allowing the egg is kind of
like having a chicken and egg story without allowing the chicken..
or is it the egg.. oh I lost track...

I think I need to watch the movie again to understand what's
happening here...

Let me go away confused... don't ask me any more questions or
elaborate with more answers. Thanks. :-)

David

[Paul Moore]

Post by David Lyon
ok - I get it.....

[...]

Post by David Lyon
Your whole email whilst perphaps technically correct is terribly
difficult for a software engineering person to follow.

OK, I'm sorry if my attempts to help you didn't do so.

Post by David Lyon
Let me go away confused... don't ask me any more questions or
elaborate with more answers. Thanks. :-)

Don't worry, I'll do my best not to from now on :-)

Paul.

[Nick Coghlan]

Post by David Lyon
Your whole email whilst perphaps technically correct is terribly
difficult for a software engineering person to follow.

It made perfect sense to me.

The words "eggs" brings with it a whole lot more baggage than just the
sum of the technical parts in the language core that support them
(primarily distutils and zipimport). I find it unfortunate that the name
for the distutils metadata format contains the word "egg" because it
implies much greater consensus around the philosophy behind eggs than
actually exists.

A lot of the baggage associated with the "eggs" concept is related to
the inherent conflict between different approaches to dependency management:
1. Use the system package management system for everything (preferred by
many, perhaps even most, *nix sysadmins, but not an option on Windows)
2. Create a Python specific package management system independent of the
system package manager (an area dominated by setuptools, including both
eggs and non-zipped package distributions)
3. Bundle everything into a monolithic application or framework (the
typical approach on Windows with py2exe, but also the philosophy behind
tools like virtualenv)

All 3 of those philosophies have good arguments in their favour and they
all have good arguments against them as well. Your comments about your
package management system suggest that it is just yet another entrant in
category 2 and you have said nothing to allay the concerns of those that
despise that philosophy with a passion because of the problems it causes
them when trying to manage their systems using the first philosophy.

Since the Python constituency includes developers and system
administrators that favour all 3 philosophies (and probably other
variants that I haven't thought to describe), anything that makes it
into the standard library will need to adequately balance the interests
of all parties (e.g. as has occurred in the PEP 376 metadata enhancement
discussions).

Cheers,
Nick.

[Terry Reedy]

Post by Nick Coghlan

Post by David Lyon
Your whole email whilst perphaps technically correct is terribly
difficult for a software engineering person to follow.

It made perfect sense to me.

Like David, I found it a bit disjointed too.

Post by Nick Coghlan
The words "eggs" brings with it a whole lot more baggage than just the
sum of the technical parts in the language core that support them
(primarily distutils and zipimport). I find it unfortunate that the name
for the distutils metadata format contains the word "egg" because it
implies much greater consensus around the philosophy behind eggs than
actually exists.
A lot of the baggage associated with the "eggs" concept is related to
1. Use the system package management system for everything (preferred by
many, perhaps even most, *nix sysadmins, but not an option on Windows)
2. Create a Python specific package management system independent of the
system package manager (an area dominated by setuptools, including both
eggs and non-zipped package distributions)
3. Bundle everything into a monolithic application or framework (the
typical approach on Windows with py2exe, but also the philosophy behind
tools like virtualenv)
All 3 of those philosophies have good arguments in their favour and they
all have good arguments against them as well. Your comments about your
package management system suggest that it is just yet another entrant in
category 2 and you have said nothing to allay the concerns of those that
despise that philosophy with a passion because of the problems it causes
them when trying to manage their systems using the first philosophy.
Since the Python constituency includes developers and system
administrators that favour all 3 philosophies (and probably other
variants that I haven't thought to describe), anything that makes it
into the standard library will need to adequately balance the interests
of all parties (e.g. as has occurred in the PEP 376 metadata enhancement
discussions).

However, the above clarifies for me what the alternatives and issues
are. Thank you for posting.

Terry Jan Reedy

[David Lyon]

Post by Nick Coghlan
The words "eggs" brings with it a whole lot more baggage than just the
sum of the technical parts in the language core that support them
(primarily distutils and zipimport).

Well, in this case, (talking metaphorically) we have the ability
to roll the eggs, crack a whole in them and suck out the contents
(deal with a package in a zipped egg)

So metaphorically we could say that python can work with egg shells..

As for what's in the egg... well lets just say that it's a bit floaty..

And perphaps that is the best way for things to be for a while.

Post by Nick Coghlan
I find it unfortunate that the name
for the distutils metadata format contains the word "egg" because it
implies much greater consensus around the philosophy behind eggs than
actually exists.

I see it a different way. I thinks eggs are simple - as in like a java
bean. A simple way to move a package from one place to another.

What seems to have gone wrong is that there is a lot of pioneering
and interconnected and interdependent technology within them. They're
an egg.. but in the past they've had little monsters that bite your
fingers when you try to put them in the pan... :-)

I think "Egg" term is very good. But maybe we are best not trying
to over-specify their contents.

Maybe we should say it has certain things (EGG_INFO, PACKAGE DATA)
as in (YOLK, WHITE) and pretty much leave it at that. If more detail
is required - rtm.

Post by Nick Coghlan
A lot of the baggage associated with the "eggs" concept is related to

That's not an egg problem. That's a packaging/metadata problem.

It's the package dependency issue that's the problem. That's a distutils
problem.

Post by Nick Coghlan
1. Use the system package management system for everything (preferred by
many, perhaps even most, *nix sysadmins, but not an option on Windows)

Yes, because the package dependency issues are just so great.

Post by Nick Coghlan
2. Create a Python specific package management system independent of the
system package manager (an area dominated by setuptools, including both
eggs and non-zipped package distributions)

More work needs to go into distutils. Not taking away from any existing
work - but setuptools has relied on the deficiencies of distutils to
gain a foothold.

Fix distutils (give me time to think..) and the need for setuptools and
any further fork is probably negated.

Post by Nick Coghlan
3. Bundle everything into a monolithic application or framework (the
typical approach on Windows with py2exe, but also the philosophy behind
tools like virtualenv)

Windows users are using py2exe and other products over distutils. To a
normal windows developer, distutils makes imho no sense in the way that
it goes about things now.

For example, very simple concepts like "program directories", (where
you stick the program) isn't an available option in distutils. But
it is the first thing that you need to know in a windows program.

So it's very hard to get to step 1...

Post by Nick Coghlan
Your comments about your
package management system suggest that it is just yet another entrant in
category 2 and you have said nothing to allay the concerns of those that
despise that philosophy with a passion because of the problems it causes
them when trying to manage their systems using the first philosophy.

I'm a windows user.. I can't be in category #2..

I'm in category #1, have nothing... (except now my own tool)

Post by Nick Coghlan
Since the Python constituency includes developers and system
administrators that favour all 3 philosophies (and probably other
variants that I haven't thought to describe), anything that makes it
into the standard library will need to adequately balance the interests
of all parties (e.g. as has occurred in the PEP 376 metadata enhancement
discussions).

Well at least you are saying that there is some way of reconciling
all the different options...

There's an awful lot to take in, and there must be 20,000 lines of
emails for every 1 line of python code that is required to fix this
thing.

Take care

David

[Nick Coghlan]

Post by David Lyon
There's an awful lot to take in, and there must be 20,000 lines of
emails for every 1 line of python code that is required to fix this
thing.

Yep, which goes way back to one of my first emails in this thread:
compared to the social aspects, the technical aspects of packaging tools
are relatively straightforward :)

It's great to see some energy directed towards solving these issues, but
I think it's important for those trying to contribute to realise what
they're dealing with. I just hope I don't kill their enthusiasm in the
process :P

Cheers,
Nick.

[Jesse Noller]

Post by David Lyon

Post by Nick Coghlan
The words "eggs" brings with it a whole lot more baggage than just the
sum of the technical parts in the language core that support them
(primarily distutils and zipimport).

Well, in this case, (talking metaphorically) we have the ability
to roll the eggs, crack a whole in them and suck out the contents
(deal with a package in a zipped egg)
So metaphorically we could say that python can work with egg shells..
As for what's in the egg... well lets just say that it's a bit floaty..
And perphaps that is the best way for things to be for a while.

Post by Nick Coghlan
I find it unfortunate that the name
for the distutils metadata format contains the word "egg" because it
implies much greater consensus around the philosophy behind eggs than
actually exists.

I see it a different way. I thinks eggs are simple - as in like a java
bean. A simple way to move a package from one place to another.
What seems to have gone wrong is that there is a lot of pioneering
and interconnected and interdependent technology within them. They're
an egg.. but in the past they've had little monsters that bite your
fingers when you try to put them in the pan... :-)
I think "Egg" term is very good. But maybe we are best not trying
to over-specify their contents.
Maybe we should say it has certain things (EGG_INFO, PACKAGE DATA)
as in (YOLK, WHITE) and pretty much leave it at that. If more detail
is required - rtm.

Post by Nick Coghlan
A lot of the baggage associated with the "eggs" concept is related to

That's not an egg problem. That's a packaging/metadata problem.
It's the package dependency issue that's the problem. That's a distutils
problem.

Post by Nick Coghlan
1. Use the system package management system for everything (preferred by
many, perhaps even most, *nix sysadmins, but not an option on Windows)

Yes, because the package dependency issues are just so great.

Post by Nick Coghlan
2. Create a Python specific package management system independent of the
system package manager (an area dominated by setuptools, including both
eggs and non-zipped package distributions)

More work needs to go into distutils. Not taking away from any existing
work - but setuptools has relied on the deficiencies of distutils to
gain a foothold.
Fix distutils (give me time to think..) and the need for setuptools and
any further fork is probably negated.

Post by Nick Coghlan
3. Bundle everything into a monolithic application or framework (the
typical approach on Windows with py2exe, but also the philosophy behind
tools like virtualenv)

Windows users are using py2exe and other products over distutils. To a
normal windows developer, distutils makes imho no sense in the way that
it goes about things now.
For example, very simple concepts like "program directories", (where
you stick the program) isn't an available option in distutils. But
it is the first thing that you need to know in a windows program.
So it's very hard to get to step 1...

Post by Nick Coghlan
Your comments about your
package management system suggest that it is just yet another entrant in
category 2 and you have said nothing to allay the concerns of those that
despise that philosophy with a passion because of the problems it causes
them when trying to manage their systems using the first philosophy.

I'm a windows user.. I can't be in category #2..
I'm in category #1, have nothing... (except now my own tool)

Post by Nick Coghlan
Since the Python constituency includes developers and system
administrators that favour all 3 philosophies (and probably other
variants that I haven't thought to describe), anything that makes it
into the standard library will need to adequately balance the interests
of all parties (e.g. as has occurred in the PEP 376 metadata enhancement
discussions).

Well at least you are saying that there is some way of reconciling
all the different options...
There's an awful lot to take in, and there must be 20,000 lines of
emails for every 1 line of python code that is required to fix this
thing.
Take care
David

I really do think this mail thread needs to move to disutils-sig or
python-ideas.

jesse

[Antoine Pitrou]

Post by Jesse Noller
I really do think this mail thread needs to move to disutils-sig or
python-ideas.

+1