6 ms·

sigh If you want to help, check out the Python-dev thread where this is being hashed out ad-infinitum rather than flamed to death: http://mail.python.org/piperm

by jnoller 14y ago

sigh If you want to help, check out the Python-dev thread where this is being hashed out ad-infinitum rather than flamed to death: http://mail.python.org/pipermail/python-dev/2012-June/120430.html http://mail.python.org/pipermail/python-dev/2012-June/120430... - for the tl;dr crowd - yeah, things have problems, want to fix.

gitarr 14y ago
Yes! Every developer should know one of the very helpful and working ways of doing things in open source software development: "Stop complaining, fix it." It's one thing to complain about closed source software that you have to use and probably paid for as well. But a very different one to complain about free and open source software that you want to use. Stop the bickering, start the work on fixing the problem instead.
- jnoller 14y ago
  I just want people to know there are avenues to help, and that core developers and many others aren't blind to the mistake, missteps and other things wrong. I'm exhausted by the vitriol; I'd ignore a bug report (and have) that described things as idiotic, and there are avenues for people to help chime in and guide the future. Nothing is unfixable.
  - rfugger 14y ago
    I didn't see any vitriol in the article.
    - the_mitsuhiko 14y ago
      > I didn't see any vitriol in the article. I hope there was not because that was not my intention at all. It's more an observation that replacing things with other things is a dangerous thing because you can easily dismiss parts of the design as “useless” by accident. I had the feeling that happened when ditching setuptools and that's a mistake that problem should not be repeated. I made that mistake in the past already at one point where I tried to replace the Python logging library and I missde perfectly valid usecases in the process.
  - veemjeem 14y ago
    As a newbie coming into the python world, from the nodejs world, it's somewhat hard for me to just start fixing a broken system. It took me a few hours to fully understand the npm system, yet I still cannot understand the combination of tools python has -- virtualenv, burrito, pip, easy_install, etc. Sometimes I can get things to install with easy_install, but not with pip, and sometimes it's easier the other way around, mostly I simply don't comprehend what's going on under the covers so it's hard for me to start fixing. I'd like to fix it too, but honestly I don't think people would adopt my package manager if I were to create something new from scratch.
    - pyre 14y ago
      virtualenv => a way of isolating a set of python libraries. Sort of like a chroot for Python libraries. (Python's version of Perl's perlbrew or Ruby's rvm) pip => Supercedes easy_install, but as this post mentions, doesn't cover 100% of the use-cases (just the most common ones). Think of it as Python's version of Perl's cpanminus (aka cpanm). burrito => The README says it all: With one command, have a working Python virtualenv + virtualenvwrapper environment virtualenvwrapper => A set of shell scripts/functions for working with multiple virtualenvs in development. Basically sets them all up in a central location so that you can do things like: workon my-websight-library-set
      - aaronh 14y ago
        how is nobody aware of PythonBrew? to me it seems like the best and most comprehensive environment manager. it supports separate Python versions as well as virtual envs, in a very simple command line interface that is reminiscent of Ruby's RVM: https://github.com/utahta/pythonbrew https://github.com/utahta/pythonbrew
        pyre 14y ago
        I have heard of pythonbrew[1][2][3], but I didn't feel the need to list everything. [1] http://news.ycombinator.com/item?id=3183721 http://news.ycombinator.com/item?id=3183721 [2] http://news.ycombinator.com/item?id=2795333 http://news.ycombinator.com/item?id=2795333 [3] http://news.ycombinator.com/item?id=2856131 http://news.ycombinator.com/item?id=2856131
- dynamichype 14y ago
  While I don't think it's to the same degree, I do think that "fix it" is at least in the same category of "things that turn people off OS" as RTFM. There are different level/kinds/what-have-you of users/coders. There are wizards who write operating systems, grey-beards who write API's, application developers, scripters, and application users. It's perfectly valid for one kind of person to complain to another with no hope of fixing the issue themselves. I work on open-source middleware both for a living and for fun and I welcome complaints about particular use-cases just as much (if not more than) patches. Cultural silos do exist between the different kinds/levels of coders and these kinds of heated conversations are needed. I can't even count how many times I've received a complaint from an app developer that ended up being a valid use-case that I had not foreseen. In fact, most of the time fixes for these issues are easy on my end. These complaints are helping me expand the user-base and utility of my code. In cases where the fix is not simple, it means there is a deeper architectural issue that I need to put on the road map. Even if they hurt my pride occasionally, these users are helping me and are contributing.
the_mitsuhiko 14y ago
> 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!)
  - 14y ago
clinth 14y ago
I think you missed the subtext. The article wasn't projecting hate, it was describing how previous hateful reactions have spawned incomplete replacements, and have made the problem worse (edit: or at least more complicated). This article is an explanation of the mechanics of that process: why packaging isn't great. It's a software engineering lesson about use cases and partial supersets of features. I really enjoyed reading it.

by jnoller 14y ago

gitarr 14y ago

Yes! Every developer should know one of the very helpful and working ways of doing things in open source software development: "Stop complaining, fix it." It's one thing to complain about closed source software that you have to use and probably paid for as well. But a very different one to complain about free and open source software that you want to use. Stop the bickering, start the work on fixing the problem instead.

jnoller 14y ago
I just want people to know there are avenues to help, and that core developers and many others aren't blind to the mistake, missteps and other things wrong. I'm exhausted by the vitriol; I'd ignore a bug report (and have) that described things as idiotic, and there are avenues for people to help chime in and guide the future. Nothing is unfixable.
- rfugger 14y ago
  I didn't see any vitriol in the article.
  - the_mitsuhiko 14y ago
    > I didn't see any vitriol in the article. I hope there was not because that was not my intention at all. It's more an observation that replacing things with other things is a dangerous thing because you can easily dismiss parts of the design as “useless” by accident. I had the feeling that happened when ditching setuptools and that's a mistake that problem should not be repeated. I made that mistake in the past already at one point where I tried to replace the Python logging library and I missde perfectly valid usecases in the process.
- veemjeem 14y ago
  As a newbie coming into the python world, from the nodejs world, it's somewhat hard for me to just start fixing a broken system. It took me a few hours to fully understand the npm system, yet I still cannot understand the combination of tools python has -- virtualenv, burrito, pip, easy_install, etc. Sometimes I can get things to install with easy_install, but not with pip, and sometimes it's easier the other way around, mostly I simply don't comprehend what's going on under the covers so it's hard for me to start fixing. I'd like to fix it too, but honestly I don't think people would adopt my package manager if I were to create something new from scratch.
  - pyre 14y ago
    virtualenv => a way of isolating a set of python libraries. Sort of like a chroot for Python libraries. (Python's version of Perl's perlbrew or Ruby's rvm) pip => Supercedes easy_install, but as this post mentions, doesn't cover 100% of the use-cases (just the most common ones). Think of it as Python's version of Perl's cpanminus (aka cpanm). burrito => The README says it all: With one command, have a working Python virtualenv + virtualenvwrapper environment virtualenvwrapper => A set of shell scripts/functions for working with multiple virtualenvs in development. Basically sets them all up in a central location so that you can do things like: workon my-websight-library-set
    - aaronh 14y ago
      how is nobody aware of PythonBrew? to me it seems like the best and most comprehensive environment manager. it supports separate Python versions as well as virtual envs, in a very simple command line interface that is reminiscent of Ruby's RVM: https://github.com/utahta/pythonbrew https://github.com/utahta/pythonbrew
      - pyre 14y ago
        I have heard of pythonbrew[1][2][3], but I didn't feel the need to list everything. [1] http://news.ycombinator.com/item?id=3183721 http://news.ycombinator.com/item?id=3183721 [2] http://news.ycombinator.com/item?id=2795333 http://news.ycombinator.com/item?id=2795333 [3] http://news.ycombinator.com/item?id=2856131 http://news.ycombinator.com/item?id=2856131
dynamichype 14y ago
While I don't think it's to the same degree, I do think that "fix it" is at least in the same category of "things that turn people off OS" as RTFM. There are different level/kinds/what-have-you of users/coders. There are wizards who write operating systems, grey-beards who write API's, application developers, scripters, and application users. It's perfectly valid for one kind of person to complain to another with no hope of fixing the issue themselves. I work on open-source middleware both for a living and for fun and I welcome complaints about particular use-cases just as much (if not more than) patches. Cultural silos do exist between the different kinds/levels of coders and these kinds of heated conversations are needed. I can't even count how many times I've received a complaint from an app developer that ended up being a valid use-case that I had not foreseen. In fact, most of the time fixes for these issues are easy on my end. These complaints are helping me expand the user-base and utility of my code. In cases where the fix is not simple, it means there is a deeper architectural issue that I need to put on the road map. Even if they hurt my pride occasionally, these users are helping me and are contributing.

the_mitsuhiko 14y ago

> 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!)
- 14y ago

clinth 14y ago

I think you missed the subtext. The article wasn't projecting hate, it was describing how previous hateful reactions have spawned incomplete replacements, and have made the problem worse (edit: or at least more complicated). This article is an explanation of the mechanics of that process: why packaging isn't great. It's a software engineering lesson about use cases and partial supersets of features. I really enjoyed reading it.