-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add detached-environments
to the config, so users can move the environments out of the project folder.
#1381
feat: Add detached-environments
to the config, so users can move the environments out of the project folder.
#1381
Conversation
We should probably also print a warning when we already see a populated |
@pavelzw What do you mean with warning when symlinking? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove debug work
When I have a filled .pixi directory instead of a symlink already present, we should warn the user instead of directly deleting it. |
docs/reference/pixi_configuration.md
Outdated
authentication-override-file = "/path/to/your/override.json" | ||
``` | ||
|
||
### `target-environment-directory` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this change also affect pixi global environments?
In my setup, all HOME
is persisted on a network drive. When this affects the global installation tools as well, this could break some setups
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No it doesn't indeed because of the PIXI_HOME
setting
This PR move the complete Currently it is already weird as you can specify the configuration in the projects .pixi folder but then symlinking it is not possible. |
Co-authored-by: Bas Zalmstra <[email protected]>
Co-authored-by: Bas Zalmstra <[email protected]>
@baszalmstra I looked at all your review points and updated the symlink function a little to also do something on windows. With adding a README.txt file to the .pixi folder to tell the user looking there that it was moved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💜
@@ -343,6 +378,19 @@ impl Config { | |||
/// # Returns | |||
/// | |||
/// The loaded global config | |||
/// Validate the config file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The doc is misaligned
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dammit thanks for noticing!
Was a pretty big conflict, and the magic wand didn't do its magic properly
A few thoughts that came up: This configuration option is hard to "disable" locally since it mixes two things:
My proposal would be to split the two options into something like the following: external-pixi-folder = false # or true (false is default)
external-pixi-folder-location = "/some/path/pixi-root" # (path to pixi folder root thingy) The
or we could also drop it next to the package cache (although I am unsure wether a "cache" location is the right place). On the other hand, it "is" a cache since the definition is in the lockfile). The benefit of having the pixi envs next to the cache would be that hard linking should be possible under most configurations (while the home folder might be on a different partition, or NFS, etc.). |
For documentation of thoughts, I believe these shouldn't be two things. You either want to move it or you don't. I can't see a situation where defining both has a beneficial experience as it is not explicit what it will be doing when you have those two defined but set to false. What about this, we kinda keep the same for the global config, just a rename. pixi-folder-location = "/etc/pixi_environments" Allow for relative paths in this configuration.
The only problem with that is that we move the complete Sidenote: the name is not the best yet, as we |
I'm thinking of the same idea of:
but instead using just one config /// Option to toggle project environments to be detached from the project directory
#[serde(untagged)]
enum DetachedEnvironments {
Boolean(bool),
Path(PathBuf),
}
detached-environments = Option<DetachedEnvironments>
//
// - None/Some(false): the default behavior, envs stored within `<project_root>/.pixi`
// - Some(true): toggle detached environments on, envs stored within `<pixi_cache_dir>/envs/<hash(project-x)>`
// * `<pixi_cache_dir>` would be `XDG_CACHE_HOME/pixi` or its synonym
// * By storing envs in `pixi_cache_dir` it is possible to leverage command like `pixi clean`/`pixi cache clean`
// or whatever command we will introduce to clean up caches with envs. It could be configurable, e.g.
// `pixi clean --[no-]envs`
// - Some(my_path): toggle detached environments on, envs stored in `my_path/<hash(project-x)>` This would be much more configurable yet concise and only one key is added. And later you can use |
@chawyehsu We all like your idea! I'm going to implement it like that including only moving the |
target-environments-directory
to the global configdetached-environments
to the config, so users can move the environments out of the project folder.
Fixes: #997
Todo:
deny_unknown_fields
solve-envs