Skip to content
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

Closed
maresb opened this issue Sep 23, 2024 · 8 comments · Fixed by #2361
Closed

pixi should manage its own .pixi/.gitignore #2115

maresb opened this issue Sep 23, 2024 · 8 comments · Fixed by #2361

Comments

@maresb
Copy link
Contributor

maresb commented Sep 23, 2024

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:

  1. It is a seemingly unnecessary additional installation step in light of the alternative below.
  2. Whenever the user checks out a branch from before .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 just pixi.toml!)

Bonus: repeat with .dockerignore
EDIT: I don't think Docker supports recursive .dockerignore files.

@maresb
Copy link
Contributor Author

maresb commented Sep 23, 2024

From #questions-chat

image

@maresb
Copy link
Contributor Author

maresb commented Sep 26, 2024

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 pixi.toml. Ideally I could just leave that and the rest of the pixi files untracked by Git. However, I need to modify .gitignore and be careful not to check in the changes. I rebase quite frequently, so whenever I rebase I have to stash my updated .gitignore and that causes a big mess.

@maresb
Copy link
Contributor Author

maresb commented Sep 26, 2024

We might not yet be able to entirely get rid of .gitignore in the project root due to .egg-info, see #1693 (comment).

@maresb
Copy link
Contributor Author

maresb commented Sep 27, 2024

If we get rid of .gitignore in the project root, then we will trigger pypa/hatch#304. Probably the safest approach at first is to keep both .gitignores. We could also try and add .pixi to the built-in ignores as per pypa/hatch#493.

EDIT: submitted pypa/hatch#1762 to fix this

@m-richards
Copy link

I'm working on some open-source project that doesn't use pixi, so I add my own pixi.toml. Ideally I could just leave that and the rest of the pixi files untracked by Git. However, I need to modify .gitignore and be careful not to check in the changes.

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 .git/info/exclude rather than the .gitignore to avoid accidentally checking stuff in.

@rgommers
Copy link
Contributor

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 .git/info/exclude rather than the .gitignore to avoid accidentally checking stuff in.

I've had this problem as well, and settled on keeping pixi.toml one level up in the directory tree from the root of the repo. pixi walks up, so this just works when invoking pixi from within the repo (you just have to set cwd for tasks). It has multiple benefits: no need to worry about accidentally deleting or checking in pixi.toml, and you can keep pixi.toml and pixi.lock under version control (see https://github.com/rgommers/pixi-dev-scipystack/ for an example).

maresb added a commit to maresb/hatch that referenced this issue Oct 20, 2024
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)>
maresb added a commit to maresb/hatch that referenced this issue Oct 21, 2024
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)>
maresb added a commit to maresb/pixi that referenced this issue Oct 26, 2024
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>.
maresb added a commit to maresb/pixi that referenced this issue Oct 27, 2024
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>.
@maresb
Copy link
Contributor Author

maresb commented Oct 27, 2024

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 .pixi from the .gitignore in the project root.

@maresb
Copy link
Contributor Author

maresb commented Nov 9, 2024

I believe the .pixi in .gitignore is now redundant now that #1693 has been merged.

Is it well-documented for what the .egg-info exclude is necessary? In case it's no longer necessary, then pixi no longer needs to touch .gitignore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants