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?
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
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
floris.bruynoo...@gmail.com wrote:
An argument against a generated .py file is that this won't work for
single-module
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
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
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
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_,
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
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
At 04:50 AM 2/22/2009 +0100, Tarek Ziadé wrote:
On Sun, Feb 22, 2009 at 4:30 AM, P.J. Eby p...@telecommunity.com 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_info because of a getattr
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
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
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
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 safeguard
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
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
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
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
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
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
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?
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,
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
At 07:16 PM 3/11/2009 +0100, Lennart Regebro wrote:
On Wed, Mar 11, 2009 at 19:07, P.J. Eby p...@telecommunity.com 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 to have
At 10:14 PM 3/11/2009 +0100, Lennart Regebro wrote:
On Wed, Mar 11, 2009 at 21:47, P.J. Eby p...@telecommunity.com 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
At 11:04 PM 3/11/2009 +0100, Lennart Regebro wrote:
On Wed, Mar 11, 2009 at 22:56, P.J. Eby p...@telecommunity.com 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
At 08:38 AM 3/12/2009 +0100, Lennart Regebro wrote:
On Thu, Mar 12, 2009 at 08:35, Lennart Regebro rege...@gmail.com wrote:
On Thu, Mar 12, 2009 at 03:38, P.J. Eby p...@telecommunity.com wrote:
That's not a catch 22. You simply run a 2.x setup.py with options that
cause the conversion
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
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
from
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
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
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
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-machineshttp://peak.telecommunity.com/DevCenter/EasyInstall#installing-on-un-networked-machines
and:
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
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 :
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
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?
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. So
At 10:14 AM 4/6/2009 +0200, Tarek Ziadé wrote:
On Mon, Apr 6, 2009 at 10:05 AM, Lennart Regebro rege...@gmail.com wrote:
On Mon, Apr 6, 2009 at 09:51, Tarek Ziadé ziade.ta...@gmail.com wrote:
So part of your file list is declared implicitely in your (D)VCS and
part explicitely in your setup.
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, we think
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 the
At 03:40 PM 4/6/2009 +0200, Tarek Ziadé wrote:
On Mon, Apr 6, 2009 at 3:40 PM, P.J. Eby p...@telecommunity.com 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 the glob-style pattern
At 03:53 PM 4/6/2009 +0200, Tarek Ziadé wrote:
2009/4/6 P.J. Eby p...@telecommunity.com:
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
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 da...@ar.media.kyoto-u.ac.jp:
python setup.py sdist # put everything under svn into the tarball
cd dist uncompress tarball python setup.py sdist # the
tarball
At 04:43 PM 4/6/2009 +0200, Lennart Regebro wrote:
On Mon, Apr 6, 2009 at 16:04, P.J. Eby p...@telecommunity.com 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
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 everything under svn into the tarball
cd
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
At 05:32 PM 4/6/2009 +0200, Tarek Ziadé wrote:
2009/4/6 P.J. Eby p...@telecommunity.com:
At 04:43 PM 4/6/2009 +0200, Lennart Regebro wrote:
On Mon, Apr 6, 2009 at 16:04, P.J. Eby p...@telecommunity.com wrote:
I don't understand why you're so anxious to deprecate something without
first
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,
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
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
At 02:33 PM 4/8/2009 +0200, Lennart Regebro wrote:
On Wed, Apr 8, 2009 at 14:23, Tres Seaver tsea...@palladion.com 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.
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',
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=egginfotmp
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,
At 03:03 PM 4/9/2009 +0100, Paul Moore wrote:
2009/4/9 Eric Smith e...@trueblade.com:
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
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
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.
error:
/home/tseaver/projects/Zope
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.comp...@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 RedHat 5 both use
At 10:43 AM 4/12/2009 -0700, Buck Golemon wrote:
On Sun, Apr 12, 2009 at 8:54 AM, Andrew Straw
mailto:straw...@astraw.comstraw...@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
At 11:11 AM 4/13/2009 -0700, Buck wrote:
On Apr 12, 12:46 pm, P.J. Eby p...@telecommunity.com wrote:
On Sun, Apr 12, 2009 at 8:54 AM, Andrew Straw
mailto:straw...@astraw.comstraw...@astraw.com wrote:
On the other hand, sticking the egg into the place that distutils
uses when not under
At 11:16 AM 4/13/2009 -0700, Buck wrote:
On Apr 12, 8:51 am, Tres Seaver tsea...@palladion.com 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)
At 11:23 PM 4/13/2009 +0200, Tarek Ziadé wrote:
Hello
I am working on PEP 376
http://svn.python.org/projects/peps/trunk/pep-0376.txt, 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
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).
At 09:13 AM 4/15/2009 +0200, Matthias Klose wrote:
Tarek Ziadé schrieb:
Hello
I am working on PEP 376
http://svn.python.org/projects/peps/trunk/pep-0376.txt, and there's
a part about adding an install and uninstall script into Distutils.
according to the PEP files mentioned in RECORD are
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
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),
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
At 06:02 PM 4/20/2009 +0200, Lennart Regebro wrote:
On Mon, Apr 20, 2009 at 17:07, P.J. Eby p...@telecommunity.com 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
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
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,
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
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 the
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
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
At 04:06 PM 4/21/2009 +0200, Lennart Regebro wrote:
On Tue, Apr 21, 2009 at 15:03, P.J. Eby p...@telecommunity.com 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
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.
At 11:50 PM 4/21/2009 -0400, David Lyon wrote:
On Tue, 21 Apr 2009 23:02:54 -0400, P.J. Eby p...@telecommunity.com
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 far been able to get it to uninstall
any
At 08:27 AM 4/22/2009 +0200, Lennart Regebro wrote:
On Tue, Apr 21, 2009 at 19:57, P.J. Eby p...@telecommunity.com wrote:
At 04:06 PM 4/21/2009 +0200, Lennart Regebro wrote:
On Tue, Apr 21, 2009 at 15:03, P.J. Eby p...@telecommunity.com wrote:
python2 setup.py 2to3 test
Well, yes
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
At 04:52 PM 4/22/2009 +0200, Lennart Regebro wrote:
On Wed, Apr 22, 2009 at 16:18, P.J. Eby p...@telecommunity.com 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
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
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.
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
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,
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):
http://yaneurabeya.livejournal.com/3929.html.
Comments
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,
At 07:34 PM 5/3/2009 +0200, Tarek Ziadé wrote:
2009/5/3 P.J. Eby p...@telecommunity.com:
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
At 05:54 PM 5/4/2009 +0200, Tarek Ziadé wrote:
2009/5/4 P.J. Eby p...@telecommunity.com:
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
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
At 01:11 PM 5/4/2009 -0700, Garrett Cooper wrote:
You're right -- it doesn't protect against the following ():
/full/path/to/package.egg
./package.egg
By duplicates, I meant 'package-1.0.egg' and 'package-1.1.egg', not
alternate paths to the same file.
(As for the '.' replacement, you
At 12:50 AM 5/5/2009 +0200, Tarek Ziadé wrote:
On Mon, May 4, 2009 at 7:51 PM, P.J. Eby p...@telecommunity.com wrote:
At 06:01 PM 5/4/2009 +0200, Tarek Ziadé wrote:
On Mon, May 4, 2009 at 5:48 PM, P.J. Eby p...@telecommunity.com wrote:
I don't see any point to the normalization
At 06:57 PM 5/4/2009 -0500, Ian Bicking wrote:
* I'm uncomfortable with the way entry points are scanned. I
haven't looked close enough to back it up with numbers, but I think
there's a noticeable performance degradation when the number of
installed packages becomes large. (Given the
At 08:41 AM 5/5/2009 -0400, Doug Hellmann wrote:
I don't want new functionality available to an application just
because someone has permission to install a package somewhere in the
PYTHONPATH. I would rather have plugins added to an app through an
explicit configuration step of some sort.
At 09:27 PM 5/5/2009 +0100, Floris Bruynooghe wrote:
But how can a python setup.py install know where to find this
configuration file to add it's plugin?
It doesn't. The whole point of having two stages -- discovery and
activation -- is that discovery is an automatic side-effect of
At 04:35 PM 5/5/2009 -0500, Ian Bicking wrote:
Any ideas on this? Phillip?
On Fri, May 1, 2009 at 5:07 PM, Ian Bicking
mailto:i...@colorstudy.comi...@colorstudy.com wrote:
So, a bit of a problem came up with pip and namespace
packages. Here's my understanding of what's going on:
When
At 12:03 PM 5/6/2009 +1000, Ben Finney wrote:
I don't see any advantage, in the context of this discussion, to
having an additional, incompatible naming for full-path-to-a-class.
Setuptools doesn't limit an entry point to being a class, function,
or other top-level name within a module. It
At 10:59 AM 5/6/2009 -0400, Doug Hellmann wrote:
On May 5, 2009, at 10:50 PM, P.J. Eby wrote:
At 12:03 PM 5/6/2009 +1000, Ben Finney wrote:
I don't see any advantage, in the context of this discussion, to
having an additional, incompatible naming for full-path-to-a-class.
Setuptools
At 08:28 PM 5/6/2009 +0200, Hanno Schlichting wrote:
Doug Hellmann wrote:
On May 6, 2009, at 1:46 PM, P.J. Eby wrote:
At 10:59 AM 5/6/2009 -0400, Doug Hellmann wrote:
On May 5, 2009, at 10:50 PM, P.J. Eby wrote:
At 12:03 PM 5/6/2009 +1000, Ben Finney wrote:
I don't see any advantage
?
thx
On Thu, Apr 23, 2009 at 11:19 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
2009/4/22 P.J. Eby p...@telecommunity.com:
I don't see how it can manage, e.g. a development version of a
postrelease,
with an SVN rev or date stamp on it. Such versions might not be found on
PyPI or on RPMs
1 - 100 of 503 matches
Mail list logo
