6 ms·

TBH as someone trying to use Python professionally it is extremely frustrating that basic things with regards to package management are something you have to it

TBH as someone trying to use Python professionally it is extremely frustrating that basic things with regards to package management are something you have to iterate towards, as opposed to just being obvious and default.

zomglings 6y ago
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.
  - 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.
TylerE 6y ago
One thing that has become clear to me, from playing around a bit with go, rust, and nim, is that it is astonishingly better when the language has exactly one set of tools, that everyone uses. Even if that set of tools is kinda crappy (Glances at go), it's just so nice to not have all the bikeshedding and just get on with it.
- CraigJPerry 6y ago
  I’m not familiar enough with Go but at first glance the go mod stuff seemed pretty decent. E.g. more flexible than Cargo in that you could have a large codebase with two different versions of a dependency isolated to their compile units allowing you to gradually adopt a breaking change dependency in a large code base. I was kinda bowled over with that feature (the isolation part is key). For python I’m finding poetry much more ergonomic than pipenv, it’s not just the speed difference it’s the convenience of one tool which aligns with what you’re saying although the existence of poetry doesn’t delete historical aberrations in Python’s long history.
blondin 6y ago
yea, it is. but it's a sane thing to do. recommending poetry for a beginner is a bad idea. (nothing against that package). python is a mature, old, software system. three times older than go or rust. way older than zig. these modern languages have learned from the field as a whole and implemented tools that people are taking for granted nowadays. as with any mature software system, people & companies have established their preferred ways of doing things. it's going to be hard to have the language council dictate ways of doing things. i would recommend going simple and using the standard set of modules until poetry or whatever gets into it.
- deleted 6y ago
  [deleted]
- staticassertion 6y ago
  Well, Python did set up a standard - pyproject.toml. And it's what poetry uses. It's just, uh, "light".
  - goerz 6y ago
    It's also not ready yet, missing critical features like editable installs. Right now, you still need a shim setup.py. Until pyproject.toml can actually replace setupy.py, I see little incentive to start using it: It's just one more file to add. The one exception is if the package actually has build requirements, e.g. for Cython modules.
    - zo1 6y ago
      The only reason we use pyproject.toml is because of the stupid black formatter that refuses to support setup.cfg, which every other python tool under the sun supports.
      - mixmastamyk 6y ago
        There are other formatters, some may even be better.

zomglings 6y ago

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.
- 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.

TylerE 6y ago

One thing that has become clear to me, from playing around a bit with go, rust, and nim, is that it is astonishingly better when the language has exactly one set of tools, that everyone uses. Even if that set of tools is kinda crappy (Glances at go), it's just so nice to not have all the bikeshedding and just get on with it.

CraigJPerry 6y ago
I’m not familiar enough with Go but at first glance the go mod stuff seemed pretty decent. E.g. more flexible than Cargo in that you could have a large codebase with two different versions of a dependency isolated to their compile units allowing you to gradually adopt a breaking change dependency in a large code base. I was kinda bowled over with that feature (the isolation part is key). For python I’m finding poetry much more ergonomic than pipenv, it’s not just the speed difference it’s the convenience of one tool which aligns with what you’re saying although the existence of poetry doesn’t delete historical aberrations in Python’s long history.

blondin 6y ago

yea, it is. but it's a sane thing to do. recommending poetry for a beginner is a bad idea. (nothing against that package). python is a mature, old, software system. three times older than go or rust. way older than zig. these modern languages have learned from the field as a whole and implemented tools that people are taking for granted nowadays. as with any mature software system, people & companies have established their preferred ways of doing things. it's going to be hard to have the language council dictate ways of doing things. i would recommend going simple and using the standard set of modules until poetry or whatever gets into it.

deleted 6y ago
[deleted]
staticassertion 6y ago
Well, Python did set up a standard - pyproject.toml. And it's what poetry uses. It's just, uh, "light".
- goerz 6y ago
  It's also not ready yet, missing critical features like editable installs. Right now, you still need a shim setup.py. Until pyproject.toml can actually replace setupy.py, I see little incentive to start using it: It's just one more file to add. The one exception is if the package actually has build requirements, e.g. for Cython modules.
  - zo1 6y ago
    The only reason we use pyproject.toml is because of the stupid black formatter that refuses to support setup.cfg, which every other python tool under the sun supports.
    - mixmastamyk 6y ago
      There are other formatters, some may even be better.