3 ms·

I sympathize. It is unfortunate that the python community never settled around a tool like leiningen for clojure or cargo for rust or npm for node. What we saw

I sympathize. It is unfortunate that the python community never settled around a tool like leiningen for clojure or cargo for rust or npm for node. What we saw with npm was the entire community iterating towards a feature set and everyone reaping the benefits automatically with npm updates. package-lock.json is a good example of this.

staticassertion 6y ago
I completely agree. Elsewhere we see sanity by default, in Python there's still open questions and hopeful but early stage projects.
marcinzm 6y ago
The issue is that every time the community settles on a tool a new tool is made to fix the issues with the old tool rather than just refactoring the old tool.
brundolf 6y ago
Worth noting is that cargo and npm weren't "settled around"; they were developed and presented, from the beginning, alongside the relevant compiler and runtime. There was never a question; the batteries were included. Leiningen is the weird one where people did actually settle fairly well around an unofficial solution in the absence of an official one. I think the norm with languages that forego official tooling is closer to what we've seen in Python.
- xapata 6y ago
  The Python community has considered an "official" packaging tool in the past, but in those conversations found that the community had too many preferences to find a good compromise. That's the trouble with having a highly diverse set of uses and integrations, and lots of legacy. If you're curious, the email threads about Conda and defining wheels are interesting.
  - staticassertion 6y ago
    I feel like the entire point of a BDFL is that they can just ignore this sort of thing and make the hard call, but it never happened.
    - xapata 6y ago
      On the whole, Guido's career as a BDFL was astoundingly effective. Maybe he made the right call. It'd have been a terrible idea to alienate the science community just when data science was taking off as a field.
      - neolog 6y ago
        I don't know how much the original author had to do with Python's success in the last 20 years. The success of Python in data science is because of NumPy/Scipy/Pandas. Things like packaging that needed leadership never got any.
        xapata 6y ago
        The leadership was that the science community would benefit from a science-specific tool, like Conda, and that making one ring to rule them all would be too difficult. Also, yes, Guido and many other early contributers have been been active for 30ish years.
        neolog 6y ago
        Conda isn't really science specific, just like pip isn't webdev specific.
        xapata 6y ago
        The result isn't, but the motivation was. And have you noticed who is using which tool?
        deleted 6y ago
- regularfry 6y ago
  Rubygems, and then Bundler, followed the same pattern. Neither was batteries-included, both were unofficial community efforts. Bundler directly influenced cargo.
mrweasel 6y ago
I think the Python community have largely settled on pip, just like the JavaScript community have mostly opted for npm. Personally I much prefer pip over npm, it feels much more polished.
- type0 6y ago
  but pip isn't enough and not exactly user friendly
CraigJPerry 6y ago
Yarn / npm are still in competition today i think? The js tooling is particularly immature, e.g. fake packages along with typo squatting is rife. Compare with boring old maven where that’s not been an issue in >10 years at this point.
cixinlui 6y ago
I know Python much better than I do rust or node, but I think the Python design decision was decent here: you can use different tools, but all of them should put the configuration in pyproject.toml. That file has fields which are universal and others which can depend on the exact tooling used. So build tools, repos and so on can get the info they need and at least potentially, do the right thing for code packages with different tools.

staticassertion 6y ago

I completely agree. Elsewhere we see sanity by default, in Python there's still open questions and hopeful but early stage projects.

marcinzm 6y ago

The issue is that every time the community settles on a tool a new tool is made to fix the issues with the old tool rather than just refactoring the old tool.

brundolf 6y ago

Worth noting is that cargo and npm weren't "settled around"; they were developed and presented, from the beginning, alongside the relevant compiler and runtime. There was never a question; the batteries were included. Leiningen is the weird one where people did actually settle fairly well around an unofficial solution in the absence of an official one. I think the norm with languages that forego official tooling is closer to what we've seen in Python.

xapata 6y ago
The Python community has considered an "official" packaging tool in the past, but in those conversations found that the community had too many preferences to find a good compromise. That's the trouble with having a highly diverse set of uses and integrations, and lots of legacy. If you're curious, the email threads about Conda and defining wheels are interesting.
- staticassertion 6y ago
  I feel like the entire point of a BDFL is that they can just ignore this sort of thing and make the hard call, but it never happened.
  - xapata 6y ago
    On the whole, Guido's career as a BDFL was astoundingly effective. Maybe he made the right call. It'd have been a terrible idea to alienate the science community just when data science was taking off as a field.
    - neolog 6y ago
      I don't know how much the original author had to do with Python's success in the last 20 years. The success of Python in data science is because of NumPy/Scipy/Pandas. Things like packaging that needed leadership never got any.
      - xapata 6y ago
        The leadership was that the science community would benefit from a science-specific tool, like Conda, and that making one ring to rule them all would be too difficult. Also, yes, Guido and many other early contributers have been been active for 30ish years.
        neolog 6y ago
        Conda isn't really science specific, just like pip isn't webdev specific.
        xapata 6y ago
        The result isn't, but the motivation was. And have you noticed who is using which tool?
        deleted 6y ago
regularfry 6y ago
Rubygems, and then Bundler, followed the same pattern. Neither was batteries-included, both were unofficial community efforts. Bundler directly influenced cargo.

mrweasel 6y ago

I think the Python community have largely settled on pip, just like the JavaScript community have mostly opted for npm. Personally I much prefer pip over npm, it feels much more polished.

type0 6y ago
but pip isn't enough and not exactly user friendly

CraigJPerry 6y ago

Yarn / npm are still in competition today i think? The js tooling is particularly immature, e.g. fake packages along with typo squatting is rife. Compare with boring old maven where that’s not been an issue in >10 years at this point.

cixinlui 6y ago

I know Python much better than I do rust or node, but I think the Python design decision was decent here: you can use different tools, but all of them should put the configuration in pyproject.toml. That file has fields which are universal and others which can depend on the exact tooling used. So build tools, repos and so on can get the info they need and at least potentially, do the right thing for code packages with different tools.