4 ms·

> check out the Python-dev thread where this is being hashed out ad-infinitum rather than flamed to death Where am I flaming anything to death here? The sole

> check out the Python-dev thread where this is being hashed out ad-infinitum rather than flamed to death Where am I flaming anything to death here? The sole purpose of the post was to point out that certain things worked in setuptools that broke with the introduction of pip. That's neither bashing setuptools or pip, just stating something that you can observe yourself. It's an observation of an unfortunate effect of someone else taking the work of someone else to make a new tool and missing a usecase that the old tool supported with the end result of having two tools with overlapping usecases, but neither is a superset of the other. With some modifications virtualenv + pip works perfectly fine for us. It just takes some extra work and it's unfortunate that it had to happen. Personal lesson learned: try not to replace tools in the future without understanding all the usecases of the old tool first. > If you want to help I think that's one of the big fallacies of open source: that you should fix it yourself rather than saying that something is not working. I reserve the right to feel unhappy when something does not work and I reserve the right to share my experiences with others without having to feel guilty about not helping out. I tried patching pip to be able to install binary eggs but it turned out to be impossible without replicating all the logic in easy_install because pip by design does not follow it. Rather than making pip2 I decided against it and looked at what the problem actually is: we want to have fast builds. So we could solve the problem by copying over virtualenvs and fixing the paths. Perfect? No! But it's a simple fix and solves our problem.

ianb 14y ago
I didn't put binary support into pip because (a) it didn't work well on some systems, and (b) I didn't use the other systems. I am not aware of rejected patches to support binary packages on Windows (where it would be nice to include), or even rejected patches on other systems (where I think it would be misguided). That this functionality still doesn't exist years later I think is due in part to the problem domain – people find it easier to change parts of their workflow than to add this functionality, and the whole problemspace is kind of hairy which makes it hard to advance without causing regressions in somebody else's weird workflow. (And admittedly the code is hairy too – but who wants to fix that? I don't! No one does!)
- the_mitsuhiko 14y ago
  > I didn't put binary support into pip because (a) it didn't work well on some systems, and (b) I didn't use the other systems. I am not aware of rejected patches to support binary packages on Windows (where it would be nice to include), or even rejected patches on other systems (where I think it would be misguided). I did not even manage to come up with a patch that adds binary support. I looked into it one or two months ago and the way pip finds and installs packages is very different from how easy_install does it. It looked like too big of a task for me to do in the time I allocated for it. Until two months ago I did not care at all about binary distributions. It never was an issue for me. Suddenly a requirement change and I was presented with a problem that turned out to be tricky to fix with pip but easy as pie with easy_install. This is not a criticism on either pip or you as a person, just an observation of how easy it is to miss something because it does not fit ones personal requirements. I certainly did not care about binary eggs until I had to deploy code to more than one machine and wanted to have the ability to quickly switch between releases. > And admittedly the code is hairy too – but who wants to fix that? I don't! No one does! Yes. And now it's getting replaced with a new system and I hope that's not going to make the same mistakes. I certainly don't feel like I'm up to the task of making a replacement for distutils/setuptools.
  - ianb 14y ago
    I think you are confusing "missing a requirement" with "not prioritizing a few other people's requirements". That pip is missing this feature has always been documented, I always knew it was a missing requirement, but I did not have any personal motivation to resolve that.
    - j-kidd 14y ago
      Pip is great for many many use cases, but I think it kind of get overhyped as a replacement for easy_install. People just get upset when they encounter situation where it doesn't live up to the hype.
      - slurgfest 14y ago
bootload 14y ago
"... Where am I flaming anything to death here? ..." The title. Change the title to something neutral and it will match the article. Good read.
klodolph 14y ago
> try not to replace tools in the future without understanding all the usecases of the old tool first. This is exactly why autotools is so hard to replace in the C/C++ world for distributing source packages on Linux/Unix/etc., and why CMake/SCons/Jam/etc. have only ever had success in the right niche (projects which are very large or cross-platform).
ldng 14y ago
No arguing that working on setuptool to improve it would have been better but the thing is that Phillip (setuptool) hasn't been cooperative (to say the least) and Tarek ended up forking. At least that's how I remember it, so in that light, everything on your article is true but setuptool had to be "rebooted" as pip. I think that pip + distribute intended to be a pragmatic approach you're calling for and that distutil2 is the cleanup/rewrite/redesign you said should happen after. Except it's not as clean cut as "repair setuptools with as much hacks as necessary and then rewrite the implementation once all design decisions have been finalized". That said, you're completely right, use cases were forgotten and distutils2 might have started too soon. Hopefully your article sparks interest in those others use cases.

ianb 14y ago

I didn't put binary support into pip because (a) it didn't work well on some systems, and (b) I didn't use the other systems. I am not aware of rejected patches to support binary packages on Windows (where it would be nice to include), or even rejected patches on other systems (where I think it would be misguided). That this functionality still doesn't exist years later I think is due in part to the problem domain – people find it easier to change parts of their workflow than to add this functionality, and the whole problemspace is kind of hairy which makes it hard to advance without causing regressions in somebody else's weird workflow. (And admittedly the code is hairy too – but who wants to fix that? I don't! No one does!)

the_mitsuhiko 14y ago
> I didn't put binary support into pip because (a) it didn't work well on some systems, and (b) I didn't use the other systems. I am not aware of rejected patches to support binary packages on Windows (where it would be nice to include), or even rejected patches on other systems (where I think it would be misguided). I did not even manage to come up with a patch that adds binary support. I looked into it one or two months ago and the way pip finds and installs packages is very different from how easy_install does it. It looked like too big of a task for me to do in the time I allocated for it. Until two months ago I did not care at all about binary distributions. It never was an issue for me. Suddenly a requirement change and I was presented with a problem that turned out to be tricky to fix with pip but easy as pie with easy_install. This is not a criticism on either pip or you as a person, just an observation of how easy it is to miss something because it does not fit ones personal requirements. I certainly did not care about binary eggs until I had to deploy code to more than one machine and wanted to have the ability to quickly switch between releases. > And admittedly the code is hairy too – but who wants to fix that? I don't! No one does! Yes. And now it's getting replaced with a new system and I hope that's not going to make the same mistakes. I certainly don't feel like I'm up to the task of making a replacement for distutils/setuptools.
- ianb 14y ago
  I think you are confusing "missing a requirement" with "not prioritizing a few other people's requirements". That pip is missing this feature has always been documented, I always knew it was a missing requirement, but I did not have any personal motivation to resolve that.
  - j-kidd 14y ago
    Pip is great for many many use cases, but I think it kind of get overhyped as a replacement for easy_install. People just get upset when they encounter situation where it doesn't live up to the hype.
    - slurgfest 14y ago

bootload 14y ago

"... Where am I flaming anything to death here? ..." The title. Change the title to something neutral and it will match the article. Good read.

klodolph 14y ago

> try not to replace tools in the future without understanding all the usecases of the old tool first. This is exactly why autotools is so hard to replace in the C/C++ world for distributing source packages on Linux/Unix/etc., and why CMake/SCons/Jam/etc. have only ever had success in the right niche (projects which are very large or cross-platform).

ldng 14y ago

No arguing that working on setuptool to improve it would have been better but the thing is that Phillip (setuptool) hasn't been cooperative (to say the least) and Tarek ended up forking. At least that's how I remember it, so in that light, everything on your article is true but setuptool had to be "rebooted" as pip. I think that pip + distribute intended to be a pragmatic approach you're calling for and that distutil2 is the cleanup/rewrite/redesign you said should happen after. Except it's not as clean cut as "repair setuptools with as much hacks as necessary and then rewrite the implementation once all design decisions have been finalized". That said, you're completely right, use cases were forgotten and distutils2 might have started too soon. Hopefully your article sparks interest in those others use cases.