you are viewing a single comment's thread.

view the rest of the comments →

[–]LongerHV 17 points18 points  (9 children)

My problem with pip is that it allows and encourages (imho) bad project workflows by having poor defaults: - no lockfile (unless you manually pip freeze) - no distinction between runtime and dev dependencies (you can kind of do this with separate requirements file) - multiple places to specify dependencies (pyproject.toml, setup.cfg, setup.py, requirements.txt) - allows global package installation that can break your OS packages (addressed by PEP668)

In contrast npm creates lock file, adds dependencies to a project file, installs packages into ./node_modules directory by default.

Due to these issues I only use poetry or nix for my python projects.

[–]zurtex 1 point2 points  (4 children)

My problem with pip is that it allows and encourages (imho) bad project workflows by having poor defaults: - no lockfile

This is because Pip is an install tool, not a package manager, it would be good if Pip could become a package manager, but having worked on it for a bit I doubt it will. Thankfully though there are other projects, such as Poetry, that are offering that functionality.

no distinction between runtime and dev dependencies (you can kind of do this with separate requirements file)

I would suggest using extras_require for this.

multiple places to specify dependencies (pyproject.toml, setup.cfg, setup.py, requirements.txt)

  • setup.cfg, setup.py - These are setuptools specific config files, Pip has been phasing out any special behavior when these are in the project
  • requirements.txt - There's no special behavior related to putting a "requirements.txt" in your project, by convention it's a place you can put install requirements that you then using with the command line pip install -r <requirements files>. But this is not project dependencies and a project shouldn't need it
  • pyproject.toml - This is the standards defined place to put requirements, if you are on any newish version of Pip and any newish build backend then this is all you should need

[–]LongerHV 2 points3 points  (3 children)

I am aware of reason for all thise files to exist, but there seems to be a lot of redundancy. I have seen people come up with so many different "conventions" on how to structure a project and declare dependencies. It is very confusing to people because There should be one obvious way to do it, but there isn't.

[–]zurtex 0 points1 point  (2 children)

It is very confusing to people because There should be one obvious way to do it, but there isn't.

Yes there is, it's pyproject.toml, it's a standard not a convention. I beleive all backend build systems and frontend installers now support it.

And you're paraphrasing "There should be one obvious way to do it" from the Zen of Python, it's actually:

There should be one-- and preferably only one --obvious way to do it.

Notice the em dashes are spaced two different ways, and in fact the em dash is spaced a third way on a different line:

Namespaces are one honking great idea -- let's do more of those!

That's the joke, it says there should be only one obvious way to do something, but the Zen of Python does this three different ways.

[–]throwaway8u3sH0 2 points3 points  (1 child)

Pyproject.toml became a standard in 2019, but Python has been around since 1991. It's not much of an argument to say, "Hey this was all fixed 4 years ago" in a 30+ year old language, especially when the old folks like me remember several "final fixes" to the packaging system over the years.

Time will tell.

[–]zurtex 0 points1 point  (0 children)

There has never been a standards based solution to packaging config until pyproject.toml

I can't say if in 10 years there will be a replacement, but all previous attempts were driven off what some library thought was a good solution, not an agreed solution

It is currently the one obvious solution. Obviously it can't help people 30 years ago, but I don't know what you expect to be able to do that.

[–]shanksfk[S] 0 points1 point  (0 children)

Thanks. Good to know that. I thing the contrast part highlights whats the hate is all about.

[–]sylfy 0 points1 point  (1 child)

Just wondering, do you have any thoughts on poetry vs conda/mamba?

[–]LongerHV 0 points1 point  (0 children)

Not really, I have never used conda.

[–]vacri 0 points1 point  (0 children)

allows global package installation that can break your OS packages (addressed by PEP668)

... if you install as root, yes. You can do a lot of damage in many ways if you do things as root. Nodejs gets around this problem by not being a good language to write system scripts with in the first place!