Perhaps there's just something wrong with my workflow... I'm trying to
use pip as a lighter, simpler zc.buildout, but I'm thinking of going
back to buildout. Specifically, here's what I'm doing:
1. in development, I tend to run with the latest versions of things.
pip install -U -r requirements.txt
2. I have a script that deletes old .egg-info directories so that pip
can see what versions of packages are actually in use
3. Then, I bundle my stuff up with my code in an sdist. I do a pip
freeze to pull together the list of what I'm using at that point
4. I have to massage that requirements file to eliminate develop
installs and some things that just don't install via pip (path.py,
MySQL-python
5. I run a pip install -U -r requirements.txt in the place where I'm
deploying my code. Old .egg-info directories are left behind, so
things get confused about what versions are installed.
Is anyone else actively using pip freeze/install -r? Is there some
secret to keeping it sane?
Thanks!
Kevin
p.s. it's unfortunate, but from what I've seen of RubyGems they are
already better than what we have in Python and they're progressing
faster. Not that I'll be using Ruby any time soon ;) BTW, that's
not intended as a disparaging comment about Ian's work on pip or
Philip's on setuptools, which are both significant bits of work that I
appreciate. It's just an observation.
> p.s. it's unfortunate, but from what I've seen of RubyGems they are > already better than what we have in Python and they're progressing > faster. Not that I'll be using Ruby any time soon ;) BTW, that's > not intended as a disparaging comment about Ian's work on pip or > Philip's on setuptools, which are both significant bits of work that I > appreciate. It's just an observation.
Kevin,
I remember being disappointed years ago after coming to Python from Perl.
I just couldn't believe there was no CPAN for Python.
Coming up on ten years later I still can't.
The saddest part is that, to make a sweeping generalization that I'm sure would start a flame war in other quarters, the code that would be available in PyPAN or PythonGems would be of better quality than what's available in CPAN or the Gemiverse but the distribution system is far inferior to either and, as you point out, is falling further and further behind Ruby all the time.
I've always thought this very, very strange since my earliest Python explorations.
I've thought about this myself quite a bit. My perspective, coming
from PHP, is that any packaging system is better than none.
I feel that because the evolution of Python is, well, Pythonic, that
we may not end up with something like Gems or CPAN because they
evolved (if memory serves) from some rather hacked-together solutions.
There's nothing wrong with that, of course, it simply seems that the
Python community as a whole wants to find a solution that caters to
everyone, not just caters to some and eventually kludges together
support for others.
TL;DR: We're Pythonic.
On 2009-08-26, at 16:16, "sstein...@gmail.com" <sstein...@gmail.com>
wrote:
>> p.s. it's unfortunate, but from what I've seen of RubyGems they are
>> already better than what we have in Python and they're progressing
>> faster. Not that I'll be using Ruby any time soon ;) BTW, that's
>> not intended as a disparaging comment about Ian's work on pip or
>> Philip's on setuptools, which are both significant bits of work
>> that I
>> appreciate. It's just an observation.
> Kevin,
> I remember being disappointed years ago after coming to Python from
> Perl.
> I just couldn't believe there was no CPAN for Python.
> Coming up on ten years later I still can't.
> The saddest part is that, to make a sweeping generalization that
> I'm
> sure would start a flame war in other quarters, the code that would be
> available in PyPAN or PythonGems would be of better quality than
> what's available in CPAN or the Gemiverse but the distribution system
> is far inferior to either and, as you point out, is falling further
> and further behind Ruby all the time.
> I've always thought this very, very strange since my earliest
> Python
> explorations.
Maybe I shouldn't have added that "p.s.", given that this is off-topic for this list...
On Thu, Aug 27, 2009 at 9:33 AM, Scott Lyons <scottaly...@gmail.com> wrote:
> I've thought about this myself quite a bit. My perspective, coming > from PHP, is that any packaging system is better than none.
> I feel that because the evolution of Python is, well, Pythonic, that > we may not end up with something like Gems or CPAN because they > evolved (if memory serves) from some rather hacked-together solutions. > There's nothing wrong with that, of course, it simply seems that the > Python community as a whole wants to find a solution that caters to > everyone, not just caters to some and eventually kludges together > support for others.
Perhaps this is the problem with Python's package/install setup... rather than serving anyone really well, it serves everyone kind of annoyingly.
I would rather see a great system come along that requires everyone to change how they do things but does it *really well*, then to gradually evolve the current mechanisms over a period of years until they finally reach a point where you're not yelling at your computer.
One aside: easy_install and pip actually work well enough for installing a package. It's more a matter of what happens after version X of package Z is installed and then version Y comes along and you want to either uninstall X or selectively use Y in certain places, etc. From what I've gathered, it sounds like this situation is better in RubyGems today.
Kevin
p.s. I don't actually yell at my computer. But I probably should.
On Aug 26, 2:40 pm, Kevin Dangoor <dang...@gmail.com> wrote:
> Perhaps there's just something wrong with my workflow... I'm trying to
> use pip as a lighter, simpler zc.buildout, but I'm thinking of going
> back to buildout. Specifically, here's what I'm doing:
[snip]
> Is anyone else actively using pip freeze/install -r? Is there some
> secret to keeping it sane?
I'm actively (and happily) using pip freeze/install -r, but my use
case is a bit different. Primarily in that I use almost exclusively
editable develop installs direct from VCS. For many of the packages I
depend on, actual releases are unpredictably timed and as likely to be
buggy as not; it's much more flexible to be able to pinpoint any exact
VCS revision. So I don't have issues with outdated .egg-info
directories or version confusion, which seems to be your primary
complaint.
The real solution here is to finish the pip-uninstall work I started a
while back [1]. Uninstall works fine, but it needs to automatically
uninstall-before-upgrade in a rollback-able way, which (I think) would
solve your problem of outdated .egg-info data. Since my workflow
doesn't actually require this I haven't found the time to finish it up
yet.
> The real solution here is to finish the pip-uninstall work I started a > while back [1]. Uninstall works fine, but it needs to automatically > uninstall-before-upgrade in a rollback-able way, which (I think) would > solve your problem of outdated .egg-info data. Since my workflow > doesn't actually require this I haven't found the time to finish it up > yet.
Is it up somewhere? I need this pretty regularly and might be able to help.
> > The real solution here is to finish the pip-uninstall work I started a
> > while back [1]. Uninstall works fine, but it needs to automatically
> > uninstall-before-upgrade in a rollback-able way, which (I think) would
> > solve your problem of outdated .egg-info data. Since my workflow
> > doesn't actually require this I haven't found the time to finish it up
> > yet.
> Is it up somewhere? I need this pretty regularly and might be able to
> help.
