2 ms·

Also it doesn't even matter because the real way to use both uv and npm is to switch everything to = and only update manually, rather than trusting non-major up

Also it doesn't even matter because the real way to use both uv and npm is to switch everything to = and only update manually, rather than trusting non-major updates not to break anything

galangalalgol 5mo ago
Isn't there a lock file for that? I'm mostly a rust dev, but I thought I saw a lock file in a uv project I was vibe coding
- jim33442 5mo ago
  The lockfile does more than just pin the versions of your immediate deps, so one might reset it for some other reason. Or you might want to update individual packages without caring about the specific commands for that, so you edit the package file, delete lockfile, reinstall.
  - galangalalgol 5mo ago
    But if I use uv sync and the package I want I don't ever need to toss the whole file right. In rust I'd never sign off on a mr that just randomly updated lots of deps with no reason tied to the issue they were resolving
    - jim33442 4mo ago
      Not sure. Those lockfiles don't seem really human-readable. I wouldn't approve a change that randomly changes the lockfile without explanation, but I would also want the project file to set the requirements rather than relying on the lockfile, cause that's not the lockfile's job.
chippiewill 5mo ago
But that's why you have a lockfile?
mrtranscendence 5mo ago
That doesn't work for library projects, though.
- jim33442 5mo ago
  Yeah that's true. I can't imagine someone making a lib would just install deps without specifying version ranges, but maybe they do.
rtpg 5mo ago
The distinction here is on application vs library, IMO. I basically agree that applications, as a default, `==`'ing everything makes sense. For libraries, having loose bounds might mean that users upgrade and hit issues due to a lack of an upper bound. But given how lightly maintained most projects are, the risk of upper bounds simply getting in the way are higher IMO. (Put an upper bound if you know of an issue, of course!) It's a bit tricky though. Django deps in particular tend to want to explicitly check support for newer versions, but the more I think about it the more I ask myself if this is the right strategy
jimbokun 5mo ago
Or to introduce a major exploit.
elyobo 5mo ago
non major updates in the npm ecosystem are pretty reliable in my experience; my much more limited python experience suggests that semver is much less respected on that side of the fence
- jim33442 5mo ago
  I've noticed it's better in npm than in python, but still been burned enough times

Also it doesn't even matter because the real way to use both uv and npm is to switch everything to = and only update manually, rather than trusting non-major updates not to break anything

galangalalgol 5mo ago

Isn't there a lock file for that? I'm mostly a rust dev, but I thought I saw a lock file in a uv project I was vibe coding

jim33442 5mo ago
The lockfile does more than just pin the versions of your immediate deps, so one might reset it for some other reason. Or you might want to update individual packages without caring about the specific commands for that, so you edit the package file, delete lockfile, reinstall.
- galangalalgol 5mo ago
  But if I use uv sync and the package I want I don't ever need to toss the whole file right. In rust I'd never sign off on a mr that just randomly updated lots of deps with no reason tied to the issue they were resolving
  - jim33442 4mo ago
    Not sure. Those lockfiles don't seem really human-readable. I wouldn't approve a change that randomly changes the lockfile without explanation, but I would also want the project file to set the requirements rather than relying on the lockfile, cause that's not the lockfile's job.

chippiewill 5mo ago

But that's why you have a lockfile?

mrtranscendence 5mo ago

That doesn't work for library projects, though.

jim33442 5mo ago
Yeah that's true. I can't imagine someone making a lib would just install deps without specifying version ranges, but maybe they do.

rtpg 5mo ago

The distinction here is on application vs library, IMO. I basically agree that applications, as a default, `==`'ing everything makes sense. For libraries, having loose bounds might mean that users upgrade and hit issues due to a lack of an upper bound. But given how lightly maintained most projects are, the risk of upper bounds simply getting in the way are higher IMO. (Put an upper bound if you know of an issue, of course!) It's a bit tricky though. Django deps in particular tend to want to explicitly check support for newer versions, but the more I think about it the more I ask myself if this is the right strategy

jimbokun 5mo ago

Or to introduce a major exploit.

elyobo 5mo ago

non major updates in the npm ecosystem are pretty reliable in my experience; my much more limited python experience suggests that semver is much less respected on that side of the fence

jim33442 5mo ago
I've noticed it's better in npm than in python, but still been burned enough times