Re: [Python-Dev] rename of ConfigParser module?
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 module 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? http://www.python.org/dev/peps/pep-3108? ___ 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
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
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 http://peak.telecommunity.com/DevCenter/setuptools#distributing-a-setuptools-based-project, 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
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
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
