Lock a git dependency to always latest commit

[rlaphoenix]

Is it possible for poetry lock to lock a git dependency to the latest commit? As in, not the latest as of the locking, but the latest ever regardless of when the install from a lock file occurs.

Currently, my project has a second repository as sort of a package data store. My current solution is to just do poetry update <name> every now and then. However, the constant annoying chore commits to updating poetry.lock gets very frustrating.

[neersighted]

Locking to a ref and not a commit is currently not possible as it violates the principle of the lock file ensuring reproducibility as much as possible. A local path dependency with a manually-managed clone is the best way to handle this if you must not use the network to access this resource.

[rlaphoenix]

Hi, but what if I can use the network to access the resource? What I'm after is effectively having a user-defined dependency that follows a project structure that can be used to extend the main package.

[rlaphoenix]

Right now my best way of doing this would be asking the user to do a poetry add git+... themselves after git cloning the package, but this modifies the poetry.lock as well as the pyproject.toml, which isn't ideal.

[neersighted]

You likely want to rethink how you are distributing this dependency... A git submodule may be more suitable, or a post-install script or step asking the user to download the data might work better. You might even want to make the fetching of this data part of your program.

It's impossible to suggest a specific solution without more specifics, but if this is data that changes often and is independent from your program's versioning, a package dependency is likely the wrong way to distribute it to your users.

[rlaphoenix]

This is all very true. And in my project I have a way for users to just specify a path to the specific package. They can also install it any other way alternative to poetry add, e.g., poetry run python -m pip install <path>.

I guess there isn't really an ideal method here built in, without just implementing my own sort of repository system that auto-updates.