News for hackers. Stuff that matters.
Re:How to make a Python package in 2021 by hardwaresofton on Thursday April 08, 2021 @03:52AM (#26736161)
Bit of a side note but remember cargo learned a lot from generations of package managers, across languages. It essentially represents some of the best that package managers have to offer. You only get that kind of result by starting from scratch every few years (as in, rust started from scratch when the Node/NPM ecosystem had been around for years to steal ideas from, Haskell had been around for years to steal language design from, etc.).

Rust is incredibly lucky to have been created when it was because it benefits immensely from these things (I think it's the best new-to-middle-aged production-usable systems language out there today).

I agree with the idea but languages like Python and their ecosystems are really hard to move (remember python 2->3? is that even over?) -- it's a herculean and often impossible task.

Re:How to make a Python package in 2021 by lmm on Thursday April 08, 2021 @06:44AM (#26737202)
Cargo is not hugely different from Maven which has been working fine for over a decade. Yes, it takes some polished ideas from other systems, but Python has had more packaging tools come and go than several other ecosystems put together.
Re:How to make a Python package in 2021 by oblio on Thursday April 08, 2021 @07:19AM (#26737407)
+1 from Maven. And Maven was launched in 2004, 17 (!) years ago. It's almost old enough to vote.

A lot of ecosystems put on some solid horse blinders in order to avoid Java at all costs (Javascript/Node/NPM being another example). They've avoided good ideas from Java for more than a decade.

Re:How to make a Python package in 2021 by afarrell on Thursday April 08, 2021 @04:45AM (#26736499)
Migrating python2 -> python3 is hard because it requires rewriting code and because you can't really run python3 code if you depend upon python2.

If poetry create consume non-poetry packages and create packages which other package management systems can consume? If so, then:

1. Projects can move more effectively independently.

2. Projects can re-package as a single task rather than a massive rewrite effort.