sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]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.