Forwarding to the list because I wasn't smart enough to "reply-all"...
---------- Forwarded message ----------
From: Nathan R. Yergler <nathan(a)yergler.net>
Date: Feb 27, 2007 5:36 PM
Subject: Re: [Distutils] easy_install prefers source?
To: "Phillip J. Eby" <pje(a)telecommunity.com>
> >c:\...>easy_install lxml==1.1
> >
> >attempts to retrieve the source distribution rather than the available
> >Windows binary egg for PyPI.
>
> What windows binary egg for PyPI? If you mean the one for 1.1, the problem
> is that easy_install isn't reading that page, because it's a "hidden"
> version. See:
Yes, I meant the one for 1.1; I assumed (incorrectly, obviously) that
by specifying the version, easy_install would look at that particular
version page in PyPI if it existed.
>
> $ python -m easy_install -nvv lxml==1.1
> Searching for lxml==1.1
[snip]
> Downloading http://codespeak.net/lxml/lxml-1.1.tgz
>
>
> > Is this the expected behavior? I would
> >have expected easy_install to prefer binary eggs.
>
> It only prefers what it finds, and currently it won't find Cheeseshop files
> for "hidden" versions of a pacakge unless you include a -f to that page,
> e.g. -f http://cheeseshop.python.org/pypi/lxml/1.1 in this case.
Prefering what it finds makes sense, although *I* would prefer that it
found the page on PyPI with the egg ;). Is the "hiding" of versions a
Cheeseshop thing? Is there a good reason *not* to look for the
requested version page on Cheeseshop? (I'm guessing the answer to this
is "we don't look for pages, we use an RPC interface [for some
definition of RPC]", but I'll ask anyway)
Thanks,
Nathan
Hi,
I would like to see two things changed about ez_setup.py:
The "#!python" at the top should read "#!/bin/env python".
And we'd need to have a license header at the top of the file. Public
domain is the most pain-free license for us (and probably everyone), but
anything Python-compatible should work.
Best wishes,
Felix
At the PyCon sprints Jim and I were working with easy_install and
working_env under Windows and noticed some odd behavior. When within
an activated working environment, attempting to do something like:
c:\...>easy_install lxml==1.1
attempts to retrieve the source distribution rather than the available
Windows binary egg for PyPI. Is this the expected behavior? I would
have expected easy_install to prefer binary eggs.
Thanks,
Nathan
Hello
when I register a package on PyPi using "setup.py register"
There's no feedback at all in case of failure when
the classifiers are wrong (let's say, a small tipo in the License
name for example)
On the other hand, doing the same thing from the website forms
returns an accurate feedback that tells what's wrong.
It could be really nice to add this feature to setuptools, in order
to get the same feedback from the prompt
Regards
Tarek
--
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
Hi,
With the following in my setup script:
-------------
from distutils.core import setup
setup(name = 'Spiff WikiMarkup',
[...]
requires = ['Plex'],
provides = ['WikiMarkup'],
[...]
-------------
1. Distutils generates a tarball named "Spiff WikiMarkup-0.1.tar.gz". How can I
replace the space in the filename by an underscore?
2. In Python cheese shop, there is a field that shows the Python version
that is required by a listed package.
I have not found this covered in the documentation: How do you add the Python
version information into the setup script of a package?
Also, is there a complete keyword list somewhere? This list:
http://docs.python.org/dist/meta-data.html
seems to contain only few of the keywords available (for example, the "provides"
and "requires" keywords are not listed, even though covered in the previous
chapters of the documentation).
Thanks,
-Samuel
I realize if you add a message to the end of
easy_install.process_distribution that says that the package is finished
installing, you can figure out just what exactly is requiring what else.
This is hugely useful to debugging just why different pieces get
installed, and if there is a conflict.
--
Ian Bicking | ianb(a)colorstudy.com | http://blog.ianbicking.org
So, I'm trying to achieve a couple different things with workingenv, and
I'm not sure how to make it all work...
I don't want one workingenv to have unintentional links to package in
another environment. Sometimes easy_install will find a package
somewhere else on the system, which is fine, but I want it to copy it
into the workingenv. I thought the easy thing was to add
"[easy_install] always_copy = True" to distutils.cfg. And this works.
*But* always_copy doesn't work with develop eggs. So specifically
there's a problem if I want to install both distribution A and B as
editable/develop eggs, and B depends on A. I can install (via setup.py
develop) A, and then install B, but B fails with something like
error: Could not find suitable distribution for
Requirement.parse('A==0.1') (--always-copy skips system and development
eggs)
Note that 'A==0.1' is something easy_install/setuptools came up with, B
only requires 'A'.
So, it seems having always_copy on really gets in the way of development
eggs. Is there another way I can avoid sharing packages without
always_copy? Or... something, I'm not sure.
--
Ian Bicking | ianb(a)colorstudy.com | http://blog.ianbicking.org
Hi!
Yesterday, a student came to me complaining about an old distutils bug which
bit him:
http://mail.python.org/pipermail/patches/2006-August/020642.html
The patch is quite trivial and cannot possibly break something AFAICS, so
could someone please apply it? (Hmm, now that I write this; we are still
using python 2.4.4 here, so maybe it has been fixed in between?)
Ciao, / /
/--/
/ / ANS
I've received a few reports of setuptools getting installed (via
ez_setup.py) as a zip file (maybe just on Python 2.5). Is this
something new? Should I expect this possibility? (Or I can just use
--always-unzip with ez_setup.py to make sure it's always installed the
same way.)
--
Ian Bicking | ianb(a)colorstudy.com | http://blog.ianbicking.org
