I’m not really happy about the direction things are going, I felt like it was better to conform to ECMAscript standards which do have real limitations but which are supported with a wide and established ecosystem of tooling, e.g. browsers.
I feel that package.json is one of the things about Node that is very well done and worth having in new ecosystems.
I would very much like something like package.json in Python. The Python packaging word is still a mess with more and more projects now moving to pyproject.toml which still isn’t a perfect solution. Many Python packages still do not support configuration via pyproject.toml so you end up with too many configuration files. And who knows how long the pyproject.toml recommendation would hold? Once there was the terrible idea of packaging Python projects with setup.py. Now pyproject.toml is the recommendation. Who knows what is going to be next?
But when you compare that with package.json and how seamless it is, it makes you wonder how other ecosystems managed to make this stuff so complex and confusing!
Once there was the terrible idea of packaging Python projects with setup.py. Now pyproject.toml is the recommendation. Who knows what is going to be next?
The setup.py file was the standard for over twenty years. It’s dishonest to represent the gradual transition away from it and toward static declarative packaging as if the standard is changing all the time.
it makes you wonder how other ecosystems managed to make this stuff so complex and confusing!
Python has a clear set of standard packaging tools – setuptools as the standard package build backend, pip as the standard package installer, and venv as the standard project isolation mechanism – and those tools all are over a decade old.The “complexity” exists entirely in the space of people who said “I don’t like those, here’s a rickety broken pile of a dozen third-party things that each try and fail to replicate what you already would have with the standard tools”.
Just because those tools are old and established doesn’t mean they are good. All these other things exist because people need them and Python doesn’t provide them.
The only remotely mainstream application languages with worse dependency management tools than Python’s are C, C++, and arguably Haskell.
I’m not really happy about the direction things are going, I felt like it was better to conform to ECMAscript standards which do have real limitations but which are supported with a wide and established ecosystem of tooling, e.g. browsers.
I feel that
package.jsonis one of the things about Node that is very well done and worth having in new ecosystems.I would very much like something like
package.jsonin Python. The Python packaging word is still a mess with more and more projects now moving topyproject.tomlwhich still isn’t a perfect solution. Many Python packages still do not support configuration viapyproject.tomlso you end up with too many configuration files. And who knows how long thepyproject.tomlrecommendation would hold? Once there was the terrible idea of packaging Python projects withsetup.py. Nowpyproject.tomlis the recommendation. Who knows what is going to be next?But when you compare that with
package.jsonand how seamless it is, it makes you wonder how other ecosystems managed to make this stuff so complex and confusing!Truly amazing how coming from Python makes npm look like a breeze 😄
My first language was Python but once I started doing JS dev I never looked back. Amazing how fragmented it still is
The
setup.pyfile was the standard for over twenty years. It’s dishonest to represent the gradual transition away from it and toward static declarative packaging as if the standard is changing all the time.Python has a clear set of standard packaging tools – setuptools as the standard package build backend, pip as the standard package installer, and venv as the standard project isolation mechanism – and those tools all are over a decade old.The “complexity” exists entirely in the space of people who said “I don’t like those, here’s a rickety broken pile of a dozen third-party things that each try and fail to replicate what you already would have with the standard tools”.
Just because those tools are old and established doesn’t mean they are good. All these other things exist because people need them and Python doesn’t provide them.
The only remotely mainstream application languages with worse dependency management tools than Python’s are C, C++, and arguably Haskell.
o_O how that’d work? Does it mean that deno will also ship a package registry?
I assume this would only work with modules served from deno.land/x.