-
-
Notifications
You must be signed in to change notification settings - Fork 122
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
pdm: support additional index/source URLs #998
Conversation
We should definitely do the second approach I think, since it would be better if we didn't force people to refresh their lock file if they already have a pdm repo. |
Force pushed with reformat and a rebase against main that GH was nagging about :) |
@abathur I am afraid you'd need to re-base again, sorry.
On that end, could you maybe add a test case? Either add a non-pypi index to one of the examples and/or to the nix-unit testsuite? |
@phaer I'm not strictly opposed if it's simple/straightforward (and I did ponder it briefly), but I'm... not convinced it will be? :) Fair warning that this is more of a jumble of thoughts than a full narrative:
|
But wouldn't we wan't to check a hash to see whether it's the same package, anywhere? Not sure I see the problem here. Otherwise a simple unit-test is good enough IMO. |
I feel like we might be talking past each other. I have no sense of what the simple unit-test that actually exercises this feature looks like. Without the static_urls locking strategy, nothing about the additional index will end up in the lockfile. If i just added some public pypi mirror to a pyproject.toml as an extra source and called it a test, the only thing we'd be testing is that adding the extra source doesn't break anything. The lockfile will be unchanged and the fetcher will still just get the package from the first source (hardcoded pypi.org). If you see a simple way to test it, I may need a little more direction. |
pdm supports extra indexes in tool.pdm.source blocks and we can also pass a list of urls to fetchFromLegacy, so this aggregates URLs from the source blocks and passes them. I think this will unblock simple cases like getting a package that is not on pypi.org from some other index, but I imagine that there are more complex cases that will require refining this support.
Ah right, we don't know where the package came from after an install with this change. I guess we could use a custom package (i.e. .postX) to test this. But it's okay. |
I doubt this is an ideal implementation, but I'm hoping that an imperfect incremental improvement to a WIP module is acceptable :)
When I took a look at switching a project that uses a private package from the pip to WIP pdm module, I noticed that pdm did pick up the alternate index when I imported the requirements. They look something like:
I looked into how to leverage it in dream2nix and saw at least two paths:
static_urls
locking strategy so that it locks a full index-specific url for each ~file.fetchFromLegacy
already supports a single url or a list of urls, just aggregate extra sources and pass them to the fetcher.The branch name here betrays that I started with the first approach, but I backed off of that for two reasons:
file
orurl
arguments tofetchFromLegacy
and pass the fully resolvedsource.url
to the other argument, but that didn't work. Since the fetcher's in another repo, I was either going to need to go change it upstream first or introduce a variant there or figure out where to put a variant of it local to this repo. Working around it started to smell like a yak shave--especially since I'm not sure locking the files down to each index is even acceptable.Falling back to the second approach was straightforward and I've confirmed it works for my fairly simple case--getting a package that is not on pypi.org from some other index--but I imagine there are more complex cases that will require refining this support.
(But I'm not sure if that'll be by doing the second approach in a more rigorous way, or adopting the first approach?)