Skip to content

fix: comparison of None in git source subdir vs empty string#5269

Merged
baszalmstra merged 12 commits intoprefix-dev:mainfrom
wolfv:fix-lockfile-solvable
Jan 14, 2026
Merged

fix: comparison of None in git source subdir vs empty string#5269
baszalmstra merged 12 commits intoprefix-dev:mainfrom
wolfv:fix-lockfile-solvable

Conversation

@wolfv
Copy link
Member

@wolfv wolfv commented Jan 12, 2026

Description

This should fix #5226 - the git source had a empty string as subdirectory while the other one had None and thus they compared as not equal.

How Has This Been Tested?

I tested this with the numpy reproducer.

AI Disclosure

All code was written by Mr. Claude

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have added sufficient tests to cover my changes.
  • I have verified that changes that would impact the JSON schema have been made in schema/model.py.

match self {
PinnedSourceSpec::Path(spec) => write!(f, "{}", spec.path),
PinnedSourceSpec::Url(spec) => write!(f, "{}", spec.url),
PinnedSourceSpec::Git(spec) => write!(f, "{}@{}", spec.git, spec.source.commit),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this just usese the formatter from Git Source instead.

@baszalmstra
Copy link
Contributor

Im thinking to further avoid this issue, we could also type this correctly. Maybe we can just represent the root subdirectory as "" too? Or if we do want to makenthe distinction between not specified and empty we could add a new type?

@wolfv wolfv requested a review from baszalmstra January 13, 2026 20:37
@wolfv
Copy link
Member Author

wolfv commented Jan 14, 2026

There are a few (serialization) failures now because e.g. subdir: . serializes to None now. I implemented normalization for the path (./foobar == foobar == foobar/ == foobar/././// etc.).

@baszalmstra do you know the impact of this? I don't think there will be a lot of subdir: . in the wild, so hopefully not a crazy amount of lockfile churn. Alternatively, we can do normalization only when comparing the subdirs and keep faithful serialization.

@benglewis
Copy link

@wolfv If you can get it to work with a subdir, I think that that would be great, but I must agree, as a person with a git sourced PyPI package in my pixi project's pyproject.toml, I do not have a subdir. If you can maybe merge the change with churn on subdir and address that issue in another PR later on, so that those like me who are facing the lock file issues now can get this fix in the next pixi version and those with the subdir may get a fix later on, I think that this would be the better approach 🙏 (Just my 2 cents as a user of pixi)

@baszalmstra baszalmstra merged commit 7296ac7 into prefix-dev:main Jan 14, 2026
98 of 107 checks passed
@wolfv wolfv deleted the fix-lockfile-solvable branch January 14, 2026 14:49
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 this pull request may close these issues.

bug(build): lock file always invalidated by pixi-build-python git dep

3 participants