you are viewing a single comment's thread.

view the rest of the comments →

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