Constraints Are Good: Python's Metadata Dilemma • Hacker News Board

Re: Constraints Are Good: Python's Metadata Dilemma

#21

Post by TheCleric » Sat, Dec 07, 2024, 7:34 AM UTC

    Maybe the solution will be for tools like uv or poetry to warn if dynamic metadata is used and strongly discourage it. Then over time the users of packages that use dynamic metadata will start to urge the package authors to stop using it.

I wouldn’t bet on this one. I know a lot of python package maintainers who would likely rather kill their project than to adapt to a standard they don’t like. For example see flake8’s stance on even supporting pyproject.toml files which have been the standard for years: https://github.com/PyCQA/flake8/issues/234#issuecomment-8128...

I know because I’m the one that added pyproject.toml support to mypy 3.5 years ago. Python package developers can rival Linux kernel maintainers for resistance to change.

Re: Constraints Are Good: Python's Metadata Dilemma

#22

Post by the_mitsuhiko » Sat, Dec 07, 2024, 1:02 PM UTC

pdonis wrote: post #18

paulddraper wrote: post #15

Earlier quoted context omitted.

I.e. orders of magnitude longer

Orders of magnitude longer than what?

Than editable installs. The main sentry app takes ~10 seconds to pip install. I would not want to run that every code change. Also more painful to debug because the filenames in the stack trace no longer match to what you have open in your editor.

Re: Constraints Are Good: Python's Metadata Dilemma

#23

Post by bheadmaster » Sat, Dec 07, 2024, 1:14 PM UTC

the_mitsuhiko wrote: post #10

pdonis wrote: post #9

A lot of the problem seems to be driven by a desire to have editable installs. I personally have never understood why having editable installs is such an important need. When I'm working on a Python package and need to test something, I just run python -m pip install --user and I now have a local installation that I can use for testing.

That would you require to make re-installations if your local app you develop against after every code change. Very few people will want to do that and it’s potentially very slow. It’s also a step not needed by most other ecosystems.

Go (a.k.a. Golang), with its network-first import system (i.e. import "example.org/foo/bar"), has solved the problem in a surprisingly simple way. You just add a "replace" directive in a go.mod file and you can point your import (and all child imports) to any directory on the filesystem.

Re: Constraints Are Good: Python's Metadata Dilemma

#24

Post by pdonis » Sun, Dec 08, 2024, 9:35 PM UTC

the_mitsuhiko wrote: post #22

pdonis wrote: post #18

Earlier quoted context omitted.

Orders of magnitude longer than what?

Than editable installs. The main sentry app takes ~10 seconds to pip install. I would not want to run that every code change. Also more painful to debug because the filenames in the stack trace no longer match to what you have open in your editor.

> The main sentry app takes ~10 seconds to pip install.

Which is much longer than the "couple of seconds" I gave for my use case. Yes, if it takes that long, I can see how you would want some alternative.

> Also more painful to debug because the filenames in the stack trace no longer match to what you have open in your editor.\

Why not? If you do a fresh install, everything should match up. It seems like this problem would be more likely with an editable install, if things aren't kept in sync properly.

Re: Constraints Are Good: Python's Metadata Dilemma

#25

Post by [deleted] » Mon, Dec 09, 2024, 9:34 AM UTC

TheCleric wrote: post #21

Maybe the solution will be for tools like uv or poetry to warn if dynamic metadata is used and strongly discourage it. Then over time the users of packages that use dynamic metadata will start to urge the package authors to stop using it. I wouldn’t bet on this one. I know a lot of python package maintainers who would likely rather kill their project than to adapt to a standard they don’t like. For example see flake8…

[deleted]

Re: Constraints Are Good: Python's Metadata Dilemma

#26

Post by the_mitsuhiko » Mon, Dec 09, 2024, 7:32 PM UTC

pdonis wrote: post #24

the_mitsuhiko wrote: post #22

Earlier quoted context omitted.

Than editable installs. The main sentry app takes ~10 seconds to pip install. I would not want to run that every code change. Also more painful to debug because the filenames in the stack trace no longer match to what you have open in your editor.

> The main sentry app takes ~10 seconds to pip install. Which is much longer than the "couple of seconds" I gave for my use case. Yes, if it takes that long, I can see how you would want some alternative. > Also more painful to debug because the filenames in the stack trace no longer match to what you have open in your editor. \ Why not? If you do a fresh install, everything should match up. It seems like this proble…

> Why not? If you do a fresh install, everything should match up.

Absolutely not. The file names in stack traces will be from the site-packages folder in the venv instead of the local checkout.