-
Notifications
You must be signed in to change notification settings - Fork 209
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
pixi should manage its own .pixi/.gitignore
#2115
Comments
From #questions-chat |
Another situation where the current state of things is annoying: I'm working on some open-source project that doesn't use pixi, so I add my own |
We might not yet be able to entirely get rid of |
If we get rid of EDIT: submitted pypa/hatch#1762 to fix this |
I also work on an open source project where I've switched to using pixi to manage multiple environments (and finding it works great!) but the project does not use it. My workaround for this is to use the |
I've had this problem as well, and settled on keeping |
Pixi is a recent tool that manages project-specific Conda environments. The environments are created in a cache directory named `.pixi/` under the project root. They should never be included in a Python distribution. For additional discussion, see <prefix-dev/pixi#2115 (comment)>
Pixi is a recent tool that manages project-specific Conda environments. The environments are created in a cache directory named `.pixi/` under the project root. They should never be included in a Python distribution. For additional discussion, see <prefix-dev/pixi#2115 (comment)>
This has the advantage that `.pixi/` will be ignored in a self-contained way without requiring modification of the project-level `.gitignore`. This is mostly redundant with the rule defined in `GITIGNORE_TEMPLATE`, but retaining them both for the moment ensures that edge cases are better handled. See the discussion in <prefix-dev#2115>.
This has the advantage that `.pixi/` will be ignored in a self-contained way without requiring modification of the project-level `.gitignore`. This is mostly redundant with the rule defined in `GITIGNORE_TEMPLATE`, but retaining them both for the moment ensures that edge cases are better handled. See the discussion in <prefix-dev#2115>.
I have a PR up for review in #2361. I also submitted pypa/hatch#1762 to fix #2115 (comment) that should AFAIK allow for us to eventually remove |
I believe the Is it well-documented for what the |
Problem description
Currently the user (or
pixi init
) must add.pixi
to their.gitignore
to prevent Git from tracking.pixi/
. There are two issues associated with this:.pixi
was ignored, Git will stop ignoring.pixi
.Suggested alternative:
Have pixi create a
.pixi/.gitignore
file to ignore all files under.pixi/
. This way the.pixi/
directory becomes self-contained and unobtrusive from the Git perspective. And this makes initialization of new pixi projects simpler. (IMO you could also get by without.gitattributes
so then you're down to justpixi.toml
!)Bonus: repeat with.dockerignore
EDIT: I don't think Docker supports recursive
.dockerignore
files.The text was updated successfully, but these errors were encountered: