Re: [Distutils] Uninstall command, the return

At 12:17 PM 1/30/2009 +0100, Tarek Ziadé wrote: this code is still incomplete, I am waiting for PJE feedback to add the support for zip files that contains several .egg folders or zip files. But the current version is able to find a package and its metadata. What feedback are you waiting for?

Re: [Distutils] patch: solving the two major things that people dislike about setuptools, part 1

At 03:00 PM 1/22/2009 -0500, Mark Sienkiewicz wrote: Phillip J. Eby wrote: At 04:48 PM 1/20/2009 -0700, zooko wrote: So, this is just to let everyone know that any setuptools variant (including a future release of PJE's setuptools) that respects the PYTHONPATH will get at least two users! As

Re: [Distutils] GUI for Python package Management - Right w ay to install packages?

At 07:57 AM 1/30/2009 -0500, David Lyon wrote: I seem to have a prototype gui of some description running based around the PyPiXmlRpc Using that code I can locate packages, but not install or download them (strange - incomplete api i guess) Anyway, now I need a foolproof/pre-existing way to

Re: [Distutils] [Python Language Summit] Distutils / Packaging survey

At 06:39 PM 1/30/2009 +, Floris Bruynooghe wrote: On Fri, Jan 30, 2009 at 01:21:12AM +0100, Tarek Ziadé wrote: > On Fri, Jan 30, 2009 at 12:34 AM, Floris Bruynooghe > wrote: > > An argument against a generated .py file is that this won't work for > > single-module python distributions. But

Re: [Distutils] [Python Language Summit] Distutils / Packaging survey

At 05:40 PM 1/31/2009 +0900, David Cournapeau wrote: Ian Bicking wrote: > On Fri, Jan 30, 2009 at 12:39 PM, Floris Bruynooghe > I wouldn't want to use those. What goes in libdir, what goes in > datadir? I don't know, and frankly the distinctions start getting > really arbitrary. They are not a

Re: [Distutils] setuptools and shared library dependencies

At 06:57 AM 2/4/2009 +0100, Greg Landrum wrote: If I were not using setuputils, I would make sure that I had BASE/bin in my LD_LIBRARY_PATH and everything would work without problems. If I explictly add the bin directory from the egg (/usr/lib/python2.5/site-packages/BASE-0.1-py2.5-linux-i686.eg

Re: [Distutils] occasional zipimport.ZipImportError: bad local file header

At 06:43 PM 2/5/2009 +, Fadhley Salim wrote: I'm working on an automatic testing framework which installs eggs downloaded directly from the web-server. From time to time I get a very long stacktrace leading to a ZipImportError (see the pastebin link). Leading up to the error all I do is downl

Re: [Distutils] Wrong depedencies in install_lib command?

At 08:06 PM 2/11/2009 +0100, Patrick Gerken wrote: Hello, i tried to install reportlab via easy_install, which always failed while compiling some c-modules. Installing it via setup.py install worked flawlessly After a while, I found the difference. setup.py install calls the command _build_,

Re: [Distutils] Problems using easy_install to download my module

Seems to work fine for me. Perhaps you hadn't uploaded the source at that point? If you want to use SourceForge's download system, you need to include a link to the files-listing page as your downloads URL, as easy_install doesn't follow arbitrary links, it just picks up *direct* download li

Re: [Distutils] why does pkg_resources call imp.load_module?

At 02:06 PM 2/19/2009 +, Karsten Petersen wrote: Hi, I'm trying to make Google App Engine work smoothly with setuptools and I'm struggling to understand one specific piece of what pkg_resources does. Would you mind giving me a hint? The question is basically: Why does _handle_ns() in p

Re: [Distutils] Distutils 2.6.2 changes will break setuptools

At 11:55 PM 2/21/2009 +0100, Tarek Ziadé wrote: Hi Phillip, Some changes in distutils/sdist are breaking some commands in setuptools' egg_info because of a getattr that make a recursive error, I think it could be a great thing to fix it as soon as possible before Python 2.6.1 is out, I am avai

Re: [Distutils] Distutils 2.6.2 changes will break setuptools

At 04:50 AM 2/22/2009 +0100, Tarek Ziadé wrote: On Sun, Feb 22, 2009 at 4:30 AM, P.J. Eby wrote: > At 11:55 PM 2/21/2009 +0100, Tarek Ziadé wrote: >> >> Hi Phillip, >> >> Some changes in distutils/sdist are breaking some commands in >> setuptools' egg

Re: [Distutils] PEP 376 for Distutils

At 01:50 AM 2/24/2009 +0100, Tarek Ziadé wrote: I having the same problem with the version : since it is already located in PKG-INFO, there's no need to have it in the folder name; It's there so pkg_resources doesn't need to read the file in order to locate an available version of the package,

Re: [Distutils] PEP 376 for Distutils

At 09:39 AM 2/24/2009 +0100, Joachim König wrote: could the egg-info directory be put somewhere else (as a configuration/command line option)? No, since it's used to identify the installed location of the code that goes with it, ala PEP 262. In other words, sys.path is its own installation d

Re: [Distutils] PEP 376 for Distutils

At 01:33 PM 2/24/2009 +0100, Tarek Ziadé wrote: Philip wrote: > So, the uninstallation code should simply not remove file(s) that are referenced by more than one manifest in the target directory -- a relatively simple, future-proof safeguard, that doesn't require any specific knowledge of "nam

Re: [Distutils] PEP 376 for Distutils

At 04:45 PM 2/24/2009 +0100, Ronald Oussoren wrote: What about another interoperability hook for system packages: specify a file that a (system) package manager can include into the egg-info directory (or egg-file) to tell setuptools/pip that this egg is managed by the system and hence shouldn't

Re: [Distutils] PEP 376 for Distutils

At 06:21 PM 2/24/2009 +, Floris Bruynooghe wrote: On Mon, Feb 23, 2009 at 09:53:17PM -0500, P.J. Eby wrote: > So, the uninstallation code should simply not remove file(s) that are > referenced by more than one manifest in the target directory -- a > relatively simple, future-proof

Re: [Distutils] PEP 376 for Distutils

At 02:57 PM 2/24/2009 -0500, P.J. Eby wrote: At 04:45 PM 2/24/2009 +0100, Ronald Oussoren wrote: What about another interoperability hook for system packages: specify a file that a (system) package manager can include into the egg-info directory (or egg-file) to tell setuptools/pip that this

Re: [Distutils] PEP 376 for Distutils

At 09:16 AM 2/25/2009 +0100, Joachim König wrote: Tarek Ziadé wrote: ok so far, from the whole dicussion it seems that everyone agrees that the Python version is superfluous in the .egg-info files, so I'll update the PEP for this point. I'll also start to write more details about uninstallation

Re: [Distutils] [issue62] pkg_resources.WorkingSet.add_entry inconsistency

At 02:58 PM 2/25/2009 +, Arve Knudsen wrote: According to WorkingSet's documentation, it should call find_distributions with False for the only-parameter. Where in the documentation is this? It should be fixed. In reality, it passes True, however. This is correct. The documented b

Re: [Distutils] PEP 376 for Distutils

At 10:03 PM 2/25/2009 +, Floris Bruynooghe wrote: It's interesting to point out what seems to be planned for Debian: http://lists.debian.org/debian-devel/2009/02/msg00431.html Quoting just the relevant part: """ Local installation path --- When installing Python modules

Re: [Distutils] Can you collapse easy-install.pth somehow?

At 12:11 AM 3/4/2009 -0600, s...@pobox.com wrote: So I have rather casually installed a bunch of packages from PyPI using easy_install. It now contains 23 eggs, all of which get used a bit, but nowhere near as often as the standard lib or our internal stuff. Unsuccessfully stat()ing in all those

Re: [Distutils] How to find the default values for --find-links

At 05:27 PM 3/5/2009 +, Fadhley Salim wrote: In an automated build environment I need to be able to make eggs which depend on non-released "testing" eggs. These are all published to a web-server operated by my team. I know that it's possible to globally change the default URLs of the "--find

Re: [Distutils] Packages listed in Easy-Install.pth

At 11:19 PM 3/9/2009 -0400, David Lyon wrote: What I want to do is use these in a list of installed packages. And then later provide for deinstallation. I'm thinking of parsing this file to read all the package names.. My question is is there any way to do the same thing with setuptools? http

Re: [Distutils] data in a source distribution?

At 10:13 PM 3/10/2009 +0100, Arne Babenhauserheide wrote: Hi, Is it possible to include data in a source distribution? You need to specify the data files in your MANIFEST.in file -- the distutils don't do that automatically for you. Of course, if you use setuptools to create your sdist, and

Re: [Distutils] data in a source distribution?

At 12:48 PM 3/11/2009 +0100, Arne Babenhauserheide wrote: Am Mittwoch 11 März 2009 02:27:20 schrieb P.J. Eby: > You need to specify the data files in your MANIFEST.in file -- the > distutils don't do that automatically for you. Ah - OK. Thank you! > Of course, if you use setupt

Re: [Distutils] Setuptools should not depend on setuptools.

At 04:50 PM 3/11/2009 +0100, Lennart Regebro wrote: When porting setuptools to Python 3, I recently looked into doing the 3.0 development a bit nicer, by being able to run 2to3 as a part of the installation or test commands. However, this turns out to be impossible, because every part of setuptoo

Re: [Distutils] Setuptools should not depend on setuptools.

At 07:16 PM 3/11/2009 +0100, Lennart Regebro wrote: On Wed, Mar 11, 2009 at 19:07, P.J. Eby wrote: > Distutils doesn't have a "test" command... let alone an egg_info command. Well does setuptools? It's all command extensions, isn't it? > It might be easier

Re: [Distutils] Setuptools should not depend on setuptools.

At 10:14 PM 3/11/2009 +0100, Lennart Regebro wrote: On Wed, Mar 11, 2009 at 21:47, P.J. Eby wrote: > Why not just invoke: > > python3 -m unittest somemodule.somesuite > > Then there are no dependencies on distutils or setuptools. Because it needs to run 2to3 on the code first

Re: [Distutils] Setuptools should not depend on setuptools.

At 11:04 PM 3/11/2009 +0100, Lennart Regebro wrote: On Wed, Mar 11, 2009 at 22:56, P.J. Eby wrote: > If you're trying to say that you want a build process that can run without > there being a 2.x interpreter present, but starts with the same source code > base, I don't see

Re: [Distutils] Setuptools should not depend on setuptools.

At 08:38 AM 3/12/2009 +0100, Lennart Regebro wrote: On Thu, Mar 12, 2009 at 08:35, Lennart Regebro wrote: > On Thu, Mar 12, 2009 at 03:38, P.J. Eby wrote: >> That's not a catch 22. You simply run a 2.x setup.py with options that >> cause the conversion to take place bef

Re: [Distutils] Setuptools should not depend on setuptools.

At 06:20 PM 3/12/2009 +0100, Lennart Regebro wrote: I don't have many assumptions. I just want the setuptools install and tests to work as expected under both python2 and python3. And that means that python3.0 setup.py install should work. And python3.0 setup.py test would be nice too, although

Re: [Distutils] Adding a sub-command to the setup.py "build" and "develop" commands

At 02:17 AM 3/13/2009 +0100, Brian Sutherland wrote: http://pypi.python.org/pypi/van.potomo/ However, one major problem is that to modify the function of the setup.py "build" and "develop" commands one needs to do this in the setup.py: from setuptools import setup, find_packages fr

Re: [Distutils] PEP 376 and the name .egg-info?

At 06:11 PM 3/23/2009 -0700, Kevin Teague wrote: I have some confusion over the name .egg-info. From what I understand, Eggs are a packaging format that contain metadata. But if you take a Distutils installed package and put a .egg-info file or directory beside it, that doesn't make the package a

Re: [Distutils] Setuptools code

At 04:47 PM 3/29/2009 -0500, Tarek Ziadé wrote: Hi Phillip One of the task here at Pycon, will consist of splitting pkg_resources.py in smaller bits, to start to see what we are going to put back into Distutils. I think that the best approach is to work on setuptools directly. It also a benefit

Re: [Distutils] install as zip

At 10:10 PM 3/29/2009 +0200, Eric Lemoine wrote: Hi I have a Pylons-based app that I want to distribute through a custom pypi. I use "easy_install -zmaxd somedir" to get the set of eggs required to distribute my app. Some of the .eggs are zips, some others are directories. I'd like zip eggs onl

Re: [Distutils] [issue67] You can't tell easy_install not to talk to the network

By the way, these options and the procedures are also listed in the official documentation at: http://peak.telecommunity.com/DevCenter/EasyInstall#installing-on-un-networked-machines and:

Re: [Distutils] bdist_egg vs bdist_wininst oddity

At 01:14 PM 4/4/2009 +0200, Jeroen Ruigrok van der Werven wrote: So I was building two new packages for Genshi and encountered this using setuptools 0.6c9: Genshi-0.5.1-py2.6-win32.egg Genshi-0.5.1.win32-py2.6.exe Why does the python version designation and platform specifier arbitrarily change

Re: [Distutils] Deprecate MANIFEST.in

At 06:45 PM 4/5/2009 +0200, Tarek Ziadé wrote: Hello After some discussions with people at Pycon, we think that the MANIFEST template should be removed. I would like to deprecate MANIFEST.in in Distutils, in favor of a package_data that can match directories with a glob-style pattern see : http

Re: [Distutils] Deprecate MANIFEST.in

At 11:24 PM 4/5/2009 +0300, Marius Gedminas wrote: On Sun, Apr 05, 2009 at 06:45:45PM +0200, Tarek Ziadé wrote: > After some discussions with people at Pycon, we think that the > MANIFEST template should be removed. +1 for fixing the mess that setuptools + distutils manage to make out of the man

Re: [Distutils] Deprecate MANIFEST.in

At 01:53 AM 4/6/2009 +0200, Tarek Ziadé wrote: 2009/4/6 P.J. Eby : > At 06:45 PM 4/5/2009 +0200, Tarek Ziadé wrote: >> >> Hello >> >> After some discussions with people at Pycon, we think that the >> MANIFEST template should be removed. >> >> I wou

Re: [Distutils] Deprecate MANIFEST.in

At 01:49 AM 4/6/2009 +0200, Tarek Ziadé wrote: So basically, if you get a source distribution out there and work on it in your own DVCS, you are unable to create a distro. Why not? Aren't there setuptools plugins available for the common DVCSes? _

Re: [Distutils] Deprecate MANIFEST.in

At 03:11 AM 4/6/2009 +0200, Tarek Ziadé wrote: Right, that would require something else, maybe a new one, ignored by the install command and using the glob-style pattern. This means the glob-style pattern will need to have an exclude mechanism if some non-installed data are inside a directory th

Re: [Distutils] Deprecate MANIFEST.in

At 03:02 PM 4/6/2009 +0900, David Cournapeau wrote: Ben Finney wrote: > > I'm not advocating using the VCS to *generate the tarball*. I'm > talking about using the VCS to *determine what files to put in the > tarball*. > Currently, using the vcs plugin does include everything as far as I know. S

Re: [Distutils] Deprecate MANIFEST.in

At 10:14 AM 4/6/2009 +0200, Tarek Ziadé wrote: On Mon, Apr 6, 2009 at 10:05 AM, Lennart Regebro wrote: > On Mon, Apr 6, 2009 at 09:51, Tarek Ziadé wrote: >> So part of your file list is declared implicitely in your (D)VCS and >> part explicitely in your setup. > > I don't see how that would wor

Re: [Distutils] Deprecate MANIFEST.in

At 12:25 PM 4/6/2009 +0300, Marius Gedminas wrote: On Sun, Apr 05, 2009 at 07:51:41PM -0400, P.J. Eby wrote: > At 11:24 PM 4/5/2009 +0300, Marius Gedminas wrote: >> On Sun, Apr 05, 2009 at 06:45:45PM +0200, Tarek Ziadé wrote: >> > After some discussions with people at Pycon,

Re: [Distutils] Deprecate MANIFEST.in

At 08:08 PM 4/6/2009 +0900, David Cournapeau wrote: My use case is very simple, and yet very common. If you have your sources in a VCS system, say svn: python setup.py sdist # put everything under svn into the tarball cd dist && uncompress tarball && python setup.py sdist # the tarball is not t

Re: [Distutils] Deprecate MANIFEST.in

At 03:40 PM 4/6/2009 +0200, Tarek Ziadé wrote: On Mon, Apr 6, 2009 at 3:40 PM, P.J. Eby wrote: > At 03:11 AM 4/6/2009 +0200, Tarek Ziadé wrote: >> >> Right, >> that would require something else, maybe a new one, ignored by the >> install command >> and using t

Re: [Distutils] Deprecate MANIFEST.in

At 03:53 PM 4/6/2009 +0200, Tarek Ziadé wrote: 2009/4/6 P.J. Eby : > Have you ever *used* plain distutils for a significant project? I invented > the source control feature in setuptools because I was constantly ending up > with files missing from my sdists, due to forgetting to add

Re: [Distutils] Deprecate MANIFEST.in

At 11:17 AM 4/6/2009 -0300, Leonardo Santagada wrote: On Apr 6, 2009, at 8:31 AM, Lennart Regebro wrote: 2009/4/6 David Cournapeau : python setup.py sdist # put everything under svn into the tarball cd dist && uncompress tarball && python setup.py sdist # the tarball is not the same Why not

Re: [Distutils] Deprecate MANIFEST.in

At 04:43 PM 4/6/2009 +0200, Lennart Regebro wrote: On Mon, Apr 6, 2009 at 16:04, P.J. Eby wrote: > I don't understand why you're so anxious to deprecate something without > first understanding what it's for. If nobody understands it, that is in itself reason to replace it

Re: [Distutils] Deprecate MANIFEST.in

At 11:18 PM 4/6/2009 +0900, David Cournapeau wrote: P.J. Eby wrote: > At 08:08 PM 4/6/2009 +0900, David Cournapeau wrote: > >> My use case is very simple, and yet very common. If you have your >> sources in a VCS system, say svn: >> >> python setup.py sdist # put

Re: [Distutils] Deprecate MANIFEST.in

At 04:23 PM 4/6/2009 +0200, Tarek Ziadé wrote: Because we have too many ways to handle this problem right now. Then why add another one? Because AFAICT you won't be able to support the full range of existing distutils use cases without something approximating MANIFEST.in. And what is the mo

Re: [Distutils] Deprecate MANIFEST.in

At 05:32 PM 4/6/2009 +0200, Tarek Ziadé wrote: 2009/4/6 P.J. Eby : > At 04:43 PM 4/6/2009 +0200, Lennart Regebro wrote: >> >> On Mon, Apr 6, 2009 at 16:04, P.J. Eby wrote: >> > I don't understand why you're so anxious to deprecate something without >

Re: [Distutils] pkg_resource require does not seem to find my egg

At 05:04 PM 4/6/2009 -0700, Nicholas Veeser wrote: I am working on a tool we call dino which uses sqlalchemy 0.5.3 Its an update of a previous version (called dino) which uses sqlalchemy 0.4.4. For reasons I don't have to go into, I would like to have both tools installed on the same host, with

Re: [Distutils] short circuiting module lookups

At 11:54 PM 4/7/2009 +1200, Noah Gift wrote: 1. In the case of entry points for setuptools, it actually recurses into EVERY egg directory in your path, not just the egg you requested, adds them to your sys.path and additionally looks for four files inside of every egg. On a laptop on local stor

Re: [Distutils] short circuiting module lookups

At 02:23 PM 4/7/2009 -0400, Jim Fulton wrote: On Apr 7, 2009, at 9:28 AM, P.J. Eby wrote: At 11:54 PM 4/7/2009 +1200, Noah Gift wrote: 1. In the case of entry points for setuptools, it actually recurses into EVERY egg directory in your path, not just the egg you requested, adds them to your

Re: [Distutils] Plugins for the MANIFEST file

At 02:33 PM 4/8/2009 +0200, Lennart Regebro wrote: On Wed, Apr 8, 2009 at 14:23, Tres Seaver wrote: > I want *less* stuff (ideally nothing) spelled in imperative Python, with > some common declarative file replacing both the information currently in > setup.py and MANIFEST.in. I thought we were

Re: [Distutils] setup.py --install-requires?

At 01:28 PM 4/8/2009 -0700, Sridhar Ratnakumar wrote: For example, zc.catalog declares these dependencies in its setup.py install_requires=['ZODB3', 'pytz', 'setuptools', 'zope.catalog', 'zope.c

Re: [Distutils] setup.py --install-requires?

At 04:48 PM 4/8/2009 -0700, Sridhar Ratnakumar wrote: On 08/04/09 02:53 PM, P.J. Eby wrote: Something like this should do the trick: import tempfile, os.path from setuptools.sandbox import run_setup def get_requires(setup_dir, empty_tmpdir): tmpdir = tempfile.mkdtemp(prefix="eggin

Re: [Distutils] setuptools still supported on Python 2.3?

At 07:43 AM 4/9/2009 +0200, Lennart Regebro wrote: I noticed when installing setuptools on Python 2.3 that easy_install fails because it tries to import subprocess, which is a new module in 2.4. I personally do not need Python 2.3 support any longer, but the docs say it should be supported, which

Re: [Distutils] Distutils changes - end user requirements (Was: Deprecate MANIFEST.in)

At 03:03 PM 4/9/2009 +0100, Paul Moore wrote: 2009/4/9 Eric Smith : > Paul Moore wrote: >> >> An >> egg->bdist_wininst converter would fix this issue. As would everyone >> standardising on bdist_wininst (which, as per the previous message, >> appears to be prefectly feasible given that bdist_wini

Re: [Distutils] bdist_wininst on Linux (was Distutils changes - end user requirements (Was: Deprecate MANIFEST.in))

At 04:02 PM 4/9/2009 -0400, Tres Seaver wrote: Warning: Can't read registry to find the necessary compiler setting Make sure that Python modules _winreg, win32api or win32con are installed. error: /home/tseaver/projects/Zope-CVS/lib/python2.6/distutils/command/wininst-6.0ux-i686.exe: No such file

Re: [Distutils] bdist_wininst on Linux (was Distutils changes - end user requirements (Was: Deprecate MANIFEST.in))

At 01:54 PM 4/9/2009 -0700, Andrew Straw wrote: P.J. Eby wrote: > At 04:02 PM 4/9/2009 -0400, Tres Seaver wrote: >> Warning: Can't read registry to find the necessary compiler setting >> Make sure that Python modules _winreg, win32api or win32con are >> installed. &

Re: [Distutils] Distutils changes - end user requirements (Was: Deprecate MANIFEST.in)

At 05:18 PM 4/10/2009 +0100, Paul Moore wrote: Hmm, and this is *precisely* one of the things I dislike. I don't like anything being installed except on my request. I know this won't affect your use case, but for the benefit of everyone else listening, I just want to mention that there is a -

Re: [Distutils] How to make easy_install handle platlibs?

At 04:09 PM 4/10/2009 -0700, Buck wrote: I'm trying to separate platform-specific and platform-independent files on my Python installation. ./configure --prefix --exec-prefix does this nicely for Python proper, but modules seem to be a whole different story. >From my testing, distutils handles t

Re: [Distutils] How to make easy_install handle platlibs?

At 08:53 PM 4/10/2009 -0700, Buck wrote: I see the kernel version and architecture, but this is insufficient; RedHat 4 and RedHat 5 both use a 2.6 kernel, but the difference in provided libraries are sufficient to make many (most?) "impure" libraries stop working ( numpy, python-ldap, and hashlib

Re: [Distutils] How to make easy_install handle platlibs?

At 12:36 AM 4/12/2009 -0700, Buck Golemon wrote: On Fri, Apr 10, 2009 at 9:15 PM, P.J. Eby <<mailto:p...@telecommunity.com>p...@telecommunity.com> wrote: At 08:53 PM 4/10/2009 -0700, Buck wrote: I see the kernel version and architecture, but this is insufficient; RedHat 4 and RedHa

Re: [Distutils] How to make easy_install handle platlibs?

At 10:43 AM 4/12/2009 -0700, Buck Golemon wrote: On Sun, Apr 12, 2009 at 8:54 AM, Andrew Straw <straw...@astraw.com> wrote: zooko wrote: > However, it currently doesn't. Eggs built on Linux are named something > like py2.5-Linux-x86_64. To know whether such an egg

Re: [Distutils] How to make easy_install handle platlibs?

At 11:11 AM 4/13/2009 -0700, Buck wrote: On Apr 12, 12:46 pm, "P.J. Eby" wrote: > >On Sun, Apr 12, 2009 at 8:54 AM, Andrew Straw > ><<mailto:straw...@astraw.com>straw...@astraw.com> wrote: > >On the other hand, sticking the egg into the place that distu

Re: [Distutils] How to make easy_install handle platlibs?

At 11:16 AM 4/13/2009 -0700, Buck wrote: On Apr 12, 8:51 am, Tres Seaver wrote: > zooko wrote: > >> It would probably be a lot easier to improve the platform string > >> generation and comparison logic, as has been done for OS X. > > > However, it (egg naming scheme on Linux) currently doesn't.

Re: [Distutils] PEP 376 - install/uninstall script in Distutils ?

At 11:23 PM 4/13/2009 +0200, Tarek Ziadé wrote: Hello I am working on PEP 376 , and there's a part about adding an install and uninstall script into Distutils. By the way, the PEP would benefit from some clarifications and separation of

Re: [Distutils] What's missing from easy_install

At 08:56 AM 4/14/2009 -0400, Neal Becker wrote: easy_install will modify easy-install.pth. Nothing will clean it. "easy_install -mxN projectname" will. (The options mean: install multi-version (i.e. remove from the .pth), exclude scripts, and don't install dependencies). _

Re: [Distutils] PEP 376 - install/uninstall script in Distutils ?

At 09:13 AM 4/15/2009 +0200, Matthias Klose wrote: Tarek Ziadé schrieb: > Hello > > I am working on PEP 376 > , and there's > a part about adding an install and uninstall script into Distutils. according to the PEP files mentioned in RECOR

Re: [Distutils] Distutils and easy_install...

At 01:03 PM 4/16/2009 -0400, Douglas Mayle wrote: Hey everyone, I'm having an annoying problem and I was directed here to see if you knew what could be done. I'm using distutils for my package instead of setuptools because it's a command line app, and the half second that set

Re: [Distutils] Questionnaire: Why do you use setuptools?

At 02:17 AM 4/20/2009 -0500, Ian Bicking wrote: 3. Namespace packages require pkg_resources? There's a way of doing it with pkgutils, but in some way that I don't understand, pkg_resources does it better. pkgutil doesn't support zip files (or any other non-filename importers/path strings),

Re: [Distutils] The problem with Setuptools on Python 3.

At 10:19 AM 4/20/2009 +0200, Lennart Regebro wrote: I don't have a good solution to this, unless we can drop setuptools dependency on setuptools completely, and just use plain distutils for installing and testing setuptools. I still don't understand why you can't have a setup3.py that uses onl

Re: [Distutils] The problem with Setuptools on Python 3.

At 06:02 PM 4/20/2009 +0200, Lennart Regebro wrote: On Mon, Apr 20, 2009 at 17:07, P.J. Eby wrote: > I still don't understand why you can't have a setup3.py that uses only > distutils, in order to run the build2to3 on. Am I missing something? Well, the question then beco

Re: [Distutils] The problem with Setuptools on Python 3.

At 06:30 PM 4/20/2009 +0200, Lennart Regebro wrote: > Because that's the one that generates the metadata setuptools needs to run, > test itself, etc. No, setup3.py does that. I thought you couldn't import setuptools in setup3.py, for all the reasons you just described? Why do I need setup.

Re: [Distutils] The problem with Setuptools on Python 3.

At 06:31 PM 4/20/2009 +0200, Lennart Regebro wrote: Let me reformulate that: > Because that's the one that generates the metadata setuptools needs to run, > test itself, etc. Why do I need setuptools to do that? Why is not distutils enough? Because distutils doesn't have an egg_info command,

Re: [Distutils] The problem with Setuptools on Python 3.

At 07:13 PM 4/20/2009 +0200, Lennart Regebro wrote: Which still doesn't really answer the question: Why setuptools need to rely on setuptools. Because there's less duplication and chances of error that way. (Earlier versions of setuptools relied on manually-created text files, instead of usi

Re: [Distutils] Help making setuptools install more like plain distutils one

At 01:28 PM 4/20/2009 -0400, Christian Hudon wrote: Is there a way to ask setuptools to do an install that looks more like a standard distutils install? Yes, use "setup.py install --single-version-externally-managed --record=/some/file". This will install the distutils way, and record all th

Re: [Distutils] The problem with Setuptools on Python 3.

At 09:11 PM 4/20/2009 +0200, Lennart Regebro wrote: "Isolated"? What do you mean? Making a separate setup script for Python 3, at least for setuptools itself, if not having a general convention for that, since other packages may want to ship 2+3 stuff in the same package. Or, in the alterna

Re: [Distutils] The problem with Setuptools on Python 3.

At 02:26 PM 4/21/2009 +0200, Lennart Regebro wrote: So why don't I use that for setuptools? Well, because: c) The setup of setuptools requires setuptools. So to be able to do the 2to3 conversion in the setup, I need to first convert the source with 2to3. Yes, catch 22. What I still don't get i

Re: [Distutils] The problem with Setuptools on Python 3.

At 04:06 PM 4/21/2009 +0200, Lennart Regebro wrote: On Tue, Apr 21, 2009 at 15:03, P.J. Eby wrote: > python2 setup.py 2to3 test Well, yes, but it should be python 3 setup.py 2to3 test Otherwise it can't reasonably have any idea of which python to use. Why not? The 2to3 comma

Re: [Distutils] What's missing from easy_install

At 09:43 PM 4/21/2009 -0400, David Lyon wrote: The uninstaller -m option, doesn't seem to want to work for me. I haven't so far been able to get it to uninstall any packages. That's not an uninstall option; it simply ensures that the package is no longer listed in easy-install.pth file. You

Re: [Distutils] What's missing from easy_install

At 11:50 PM 4/21/2009 -0400, David Lyon wrote: On Tue, 21 Apr 2009 23:02:54 -0400, "P.J. Eby" wrote: > At 09:43 PM 4/21/2009 -0400, David Lyon wrote: > >>The uninstaller -m option, doesn't seem to want to >>work for me. >> >>I haven't so f

Re: [Distutils] The problem with Setuptools on Python 3.

At 08:27 AM 4/22/2009 +0200, Lennart Regebro wrote: On Tue, Apr 21, 2009 at 19:57, P.J. Eby wrote: > At 04:06 PM 4/21/2009 +0200, Lennart Regebro wrote: >> >> On Tue, Apr 21, 2009 at 15:03, P.J. Eby wrote: >> > python2 setup.py 2to3 test >> >> Well, ye

Re: [Distutils] RFC : Version comparison

At 11:12 AM 4/22/2009 +0200, Tarek Ziadé wrote: Hi, We worked during Pycon on version comparisons. Distutils has one but it is a bit strict, setuptools has another one, but it's a bit heuristic. We would like to propose the inclusion for Python 2.7 of a new version comparison algorithm, based o

Re: [Distutils] The problem with Setuptools on Python 3.

At 04:52 PM 4/22/2009 +0200, Lennart Regebro wrote: On Wed, Apr 22, 2009 at 16:18, P.J. Eby wrote: > Er, no. It only means that you need Python 2 to be installed *while porting > a package* to Python 3. No. It means it needs to be installed when installing the package from a

Re: [Distutils] [issue68] install local package with extras with easy_install

At 03:03 AM 4/23/2009 +, Chad wrote: I feel that the above is a bug. '.' should be treated as a path not a package name, since '.' is not a valid package name. Actually, it is. i haven't looked at the code yet, but it seems that a regular expression should be able to determine between

Re: [Distutils] General Question... .EGGs... a ny good?

At 01:52 AM 4/28/2009 -0400, David Lyon wrote: Are source distributions (ie distutils) competitive with .EGG packaging? Yes. Really the main reason to distribute egg files is if you want end-users to be able to download a single file as a plugin for your application, or certain other special

Re: [Distutils] RFC : PEP 376 - egg.info

At 10:17 AM 4/30/2009 -0400, David Lyon wrote: In summary... packages are just directories with an __init__.py file in them. Sometimes they are zipped into eggs. You are confusing "Python package" with "Python project". Projects are zipped into eggs, and may contain zero or more packages. P

Re: [Distutils] Installed Packages..

At 08:50 AM 5/1/2009 -0400, David Lyon wrote: It seems you are right... But ... when I check more closely .. I see that the above code doesn't really display all the installed packages in the site-lib directory. There are some directories in there that don't get included in the results. I would l

Re: [Distutils] RFC : PEP 376 - egg.info

At 12:03 PM 5/3/2009 +0200, Tarek Ziadé wrote: The name of each file will have to be normalized: all upper case with no extensions. Any opinions ? I don't see any point to the normalization. However, being able to install arbitrary files in .egg-info is currently supported by setuptools, an

Re: [Distutils] Anyone stuck with easy_install / has .pth file issues -- this is for you!

At 02:43 AM 5/4/2009 -0700, Garrett Cooper wrote: Hi guys, Just thought I'd might provide this script to fellow developers which fixes .pth files (easy-install.pth / .egg was the prime target -- see the comments for more details): . Comments a

Re: [Distutils] RFC : PEP 376 - egg.info

At 05:23 PM 5/4/2009 +0200, Tarek Ziadé wrote: There's another point I was thinking about in PEP 376 What about dropping the 'egg' part in 'PROJECT.egg-info' ? and replace it with 'PROJECT.info' (and make the 2.7 version compatible with PROJECT.egg-info ) I know it's a minor change, Actu

Re: [Distutils] RFC : PEP 376 - egg.info

At 07:34 PM 5/3/2009 +0200, Tarek Ziadé wrote: 2009/5/3 P.J. Eby : > At 12:03 PM 5/3/2009 +0200, Tarek Ziadé wrote: >> >> The name of each file will have to be normalized: all upper case with >> no extensions. >> >> Any opinions ? > > I don't s

Re: [Distutils] RFC : PEP 376 - egg.info

At 05:54 PM 5/4/2009 +0200, Tarek Ziadé wrote: 2009/5/4 P.J. Eby : > At 05:23 PM 5/4/2009 +0200, Tarek Ziadé wrote: >> >> There's another point I was thinking about in PEP 376 >> >> What about dropping the 'egg' part in 'PROJECT.egg-info' ? an

Re: [Distutils] RFC : PEP 376 - egg.info

At 06:31 PM 5/4/2009 +0200, Tarek Ziadé wrote: Ok then, we will have to provide extra documentation to make people understand that the '.egg-info' directory has absolutely nothing to do with egg-the-format but is rather a metadata container. On the contrary; .egg-info *is* an egg format; see th

  1   2   3   4   5   6   7   >