Re: [Python-Dev] rename of ConfigParser module?

[Alexander Michael]

On Thu, May 15, 2008 at 7:37 AM, Mark Hammond <[EMAIL PROTECTED]> wrote:
> Trying to build pywin32 from the trunk, I see:
>
> from distutils.config import PyPIRCCommand
>  File "C:\src\python-svn\lib\distutils\config.py", line 8, in 
> from ConfigParser import ConfigParser
> ImportError: No module named ConfigParser
>
> Digging a little deeper, I see:
>
> |r63242 | alexandre.vassalotti | 2008-05-15 08:07:07 +1000 (Thu, 15 May
> 2008) | 2 lines
> |
> |Renamed the ConfigParser module to 'configparser'.
>
> Is there something I've missed?

?
___
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] Invitation to try out open source code review tool

[Alexander Michael]

On Tue, May 6, 2008 at 1:26 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Tue, May 6, 2008 at 12:51 AM, Jeroen Ruigrok van der Werven
>  <[EMAIL PROTECTED]> wrote:
>  > -On [20080505 05:38], Guido van Rossum ([EMAIL PROTECTED]) wrote:
>  >  >  http://code.google.com/p/rietveld/source/browse
>  >
>  >  Is it a reference to Gerrit Rietveld (Dutch architect and furniture
>  >  designer)?
>
>  Yes, as I explain here:
>  http://code.google.com/p/rietveld/wiki/CodeReviewBackground
>
>
>  > I guess the architect part would make sense for a code review
>  >  tool. :)
>
>  That's purely a coincidence. My dad was an architect and took me on
>  trips of Rietveld's work. I also own some fairly original Zig Zag
>  chairs (much to my family's despair, as they aren't too comfortable.
>  :-)

Was it also a coincidence that Mondrian and Rietveld were both members
of the De Stijl movement? If so, a very nice one!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] how to easily consume just the parts of eggs that are good for you

[Alexander Michael]

On Wed, Apr 9, 2008 at 3:40 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>  That is indeed a problem -- but it's a social one, not a technical
>  one.  It's trivial for the publisher of an egg to change their
>  command line from "setup.py bdist_egg upload" to "setup.py sdist
>  bdist_egg upload", as soon as their users (politely) request that they do so.

I know you say it in
,
but perhaps you should be more explicit about the best practice being
to distribute an sdist as well as one or more eggs and highlight this
with some standout text like:

"""
When uploading your project to PyPI, always upload your sdist in
addition to any eggs unless you have a good idiosyncratic reason not
to. The easy_install tool can also download and install sdist's on all
platforms (universally for pure-python packages and provided compilers
are available for distributions containing python extensions), so
uploading them gives your project the widest possible audience.
"""

Perhaps this will help some the social challenges.

Regards,
Alex
___
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

[Alexander Michael]

On Sat, Mar 22, 2008 at 10:02 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > 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.

Exactly. I was attempting to suggest that we be explicit about "the
problem" being solved so it was easier for everyone interested to
verify that their "needs" (i.e. use case) will be met and that the
proposed solution solves the problem. Since the topic of the thread is
how to get rid of eggs in 2.6, the question (to me, at least) is how
to enable the functionality provided by setuptools to be provided
outside the standard library in a way that does not create pressure
for the entire python community to be assimilated into egg-ified
zombies.

Why do we have the current pressure for egg-ification? The main
pressure appears to arise from a strong desire by the python community
for a simple installation tool like CPAN that downloads and installs
the package of interest *as well as* any dependencies you don't
already have installed. Of course, it is the desire for the
dependencies to be discovered, downloaded, and installed in a manner
that honors the current state of your python environment that creates
all of the problems.

My participation may be unwanted or unwarranted due to my lack of
education/understanding, but I like to live dangerously in the hopes
of actually being helpful. With that preamble, here's my attempt at an
explicit rationale for a database of installed packages (A.K.A. The
New PEP 262):

"""
Rationale
=
It is often necessary during the course of managing a python
installation for an administrator to determine the following things:

1. If the current installation state satisfies the requirements of a
new package being considered for installation.
2. If it is safe for the administrator to upgrade or remove a package,
and if so, how (e.g. use a system-level package management tool).
3. What files to remove in order to uninstall the package (if a
system-level package management tool was not used to install it).
4. If the current installation was modified in-place or custom
configured in an way, so that such changes can be noted before
upgrading.

Furthermore, many administrators want to do as much of this as
possible with automated tools, without manually inspecting README
files, INSTALL files, or the installed code itself to determine the
list of dependencies and installed versions, so there is a desire to
be able to make the above determinations programmatically.

Current efforts to provide these capabilities without standard library
support have resulted in many users being forced to use non-standard
package management tools because other users desired these
capabilities. This proposal is motivated by a desire to provide the
minimum required infrastructure so that both segments of the python
community can peacefully coexist without getting in each others way
(i.e. the ability to "opt in" to python-based non-system-level package
managers).

Proposal

The proposal is to provide in the standard library the following capabilities:

1. List the installed packages, along with the version and dependency
list for each package.
2. Query the ownership of a currently installed package (standard
library, system-level package management tool, etc.).
3. List the files installed be specific package.
4. Recall the original message digest for each installed file to
determine if the file has been modified.

...

Alternatives

There are at least three alternatives to providing a database of
installed packages that could also potentially enable administrators
to accomplish the same ultimate goal of installing new packages and
their dependencies without breaking or interfering with the "system"
installation.

Switchable Environments
---
Eliminate the need to be careful by providing a mechanism for the
creation of and installation into what amounts to user-selectable
site-packages directories that each "inherit" from what is currently
called site-packages (something like an eggless virtualenv with a
python comannd-line option to choose the environment). Need to upgrade
a package provided by the standard library or your system-level
package manager? No Problem! Of course, this won't help you manage
your sand-boxed environment, but you can have lots of them for very
little cost (it's not a whole new python installation) so just create
a new one each time you want to change something.

Ubiquitous System Packages
--
Eliminate the need to *not* use your OS's system-level package manager
by creating the necessary infrastructure so that python packages can
easily be distributed in the major system-level packager formats (RPM,
DEB, MSI, MPKG, etc.) for all publicly released python packages. A
w

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

[Alexander Michael]

On Fri, Mar 21, 2008 at 9:31 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>  The objections to the PEP remain the same as they were then,
>  though: In the requirements, it says "we need", without saying
>  why we need. It then goes on saying "we want" (rephrased)
>  "to duplicate APT and RPM", without saying why we want that,
>  or why that brings us closer to what we need.
>
>  IOW, the PEP is lacking a rationale.

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. 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. I can't create
a library to provided these functionalities and use it downstream of
the package creator without some form of standardization to report
package versions. (Or at least without running into the assimilation
problem that setuptools has).

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.

Regards,
Alex
___
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] Capsule Summary of Some Packaging/Deployment Technology Concerns

[Alexander Michael]

On Wed, Mar 19, 2008 at 6:15 PM, Jeff Rush <[EMAIL PROTECTED]> wrote:
>  Frankly I'd like to see setuptools exploded, with those parts of general use
>  folded back into the standard library, the creation of a set of
>  non-implementation-specific documents of the distribution formats and
>  behavior, leaving a small core of one implementation of how to do it and the
>  door open for others to compete with their own implementation.

If I hazard an opinion seconding this sentiment. In my use of
setuptools, it definitely feels like it wants to be three (mostly)
independent projects:

1) The project that standardizes the concept now embodied by eggs and
provides the basic machinery to work with them (find them, introspect
metadata, "import" them, etc.), but not install them per se. This is
generally useful as common plug-in framework, if nothing else.
Currently, this "run-time support" functionality is in pkg_resources.
2) The tool you can use to build eggs (but not install them per se).
Currently this is the setuptools extension to distutils.
3) The tool for installing eggs (or their equivalent) and (optionally)
their dependencies (optionally using remote hosts) as well as
uninstalling. Currently this is easy_install (well, except for
uninstalling, which is understandable quite difficult).

Finally, there is the fourth and already separate project of PyPI:
4) The hosted repository of publicly available eggs (or their
equivalent). This should export any metadata required to resolve
dependencies relatively cheeply.

Breaking them apart will make it easier to have two separate projects
for building eggs (or their equivalents) -- one based on distutils and
the other replacing it. Even more importantly, it will make it
possible for multiple installers to be developed that scratch
particular itches. Hopefully one would eventually emerge as the
de-facto standard, but this will ultimately be decided by community
adoption.

Alex
___
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