Replies: 1 comment
-
One possible solution I explored is to use symlinks, which rye does seem to handle the way you would expect:
In the above, rye properly updates the target files without overwriting their symlinks. This means I could have a bootstrap procedure with my team that requires setting the symlinks first, before running |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
If I run
rye sync
it generates a new lockfile, and this lockfile depends on the environment I'm runningrye sync
on.For example, if I run
rye sync
on my mac then it updatesrequirements.lock
, and then if I go into docker and runrye sync
it modifiedrequirements.lock
with new dependencies for that env. So these two versions ofrequirements.lock
are oscillating.I can't find any arguments / options in rye to say "use requirements-macos.lock for this rye sync".
Is there any mechanism to say (for example) use requirements-macos.lock on macos, and requirements-linux.lock on linux? At $work we have a few known environments we want to pin (macos 14+ arm64, as well as custom amd64 linux built into a base image we deploy for prod), so we'd want to name them, use them, and ask folks to run
rye sync
with the correct args to use the correct lockfile based on their env.It'd be extra amazing if it could be declared/linked to the active virtualenv at setup time similar to the toolchain such that future invocations of
rye sync
used the correct lock files.Thanks!
Beta Was this translation helpful? Give feedback.
All reactions