-
Notifications
You must be signed in to change notification settings - Fork 54
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
Poetry export
should use per-package --index-url instead of single --extra-index-url
#37
Comments
I guess a new flag |
I can work on that! |
@estyxx I'm sure it'd be much appreciated if you could get a PR started. Maybe you're right, a It was just a suggestion though, the finer details/requirements of the feature will appear as the implementation goes. Or would you rather have a more concrete outline of what the feature should look like first? We can brainstorm on that. |
@sinoroc
what do you think? |
I do not know the code base, to be able to judge on the implementation. I was suggesting we brainstorm on what the UX should look like and what the output should look like for some particular examples of inputs. But looks like you already have a PR ready, so I'm a bit too slow... :D For example:
|
@sinoroc
Think this option could be omitted now that each package has his
Think I have to check if there is the "authenticated URL" in the package object, and put that one instead in that case |
I am re-reading the "Requirements File Format" section in pip's documentation:
Are we sure that the output we are trying to generate here is conform? |
@sinoroc It seems to be some understatement in docs, because as far as I remember per-package flags simply work, but it would be good to a) verify if it's still true with the actual pip version b) create an issue on pip repo to clarify that. About the naming - I would keep it direct, e.g. --per-package-indices |
Yes, please. Let us know.
Feels like it would be nicer to stay in the spirit of the other flags |
@sinoroc I get the point, but |
@estyxx appreciate you starting to look into this. 👍 @sinoroc you are correct, the Additionally, seems
I do not think this has changed since these issues. The only sure fire way to ensure the right package is used us to rely on a direct origin url. So use the file url explicitly. The only special case we should support is when PyPI is disabled, which I think should already be the case by refering the private the repo as the index (if not - bug?). The following is what we should discuss first.
For (2), my prefernce is no. This is because, by doing so we will be encouraging a not so good practice of having same package versions overriden in private indexes. In cases where a proxy is used this should be used as the index and not as an extra index (disabling PyPI). As for (1), I would think this should be what the flag toggles ( @jaklan as I have pointed out above, a per-package option might not be feasible. The only way I can think of to support the custom ordering is using PEP 610. |
@jaklan I meant we could try to keep a |
@abn Thanks for the additional info. Should the output of Comparatively: are If indeed [Thinking about all this, I feel like I have already tried to tackle this in a non-poetry context and came to the conclusion that it was not possible] |
I don't know what kind of exports poetry is going to support in the future, but think is kind of natural that different exports can have differents flags and options... maybe we should think to validate them based on the export format selected... direct origin URL seems a good option btw... |
@abn thanks for the detailed explanation! Just for the record: I've done some tests and can confirm per-package indices simply doesn't work - I got the impression it was possible in the past, but maybe it was just a false memory ;) Anyway, I agree the solution you proposed seems to be the only reasonable one for the moment, but I also see it's not the most trivial one, so without proper user demand it rather can wait. Just to quote the workaround for the future viewers from one of the above links:
PS I agree with @estyxx about not being afraid of format specific flags, it could be hard to avoid them when the next formats are introduced anyway |
On a side note... As I have already noted in this (unrelated) tox ticket: I feel like a thing that might be missing in the Python packaging ecosystem is a requirement notation such as:
I believe this would fit quite well into
|
I opened a discussion on the topic: |
As far as I understood, the philosophy from the point of view of pip, and PyPI (and I guess PyPA ecosystem in general) is that indexes should be indistinguishable, interchangeable. If 2 projects of the same name exist on 2 indexes, it should be assumed that they are the exact same project. And 2 distributions of the same name and version number should be assumed to be the exact same distribution and so it does not matter from which one we fetch. In other words:
-- pfmoore, pypa/pip#5045 (comment) So for our current issue, it is further proof to me that relying on [Short of relying on direct URLs If one needs to circumvent this behaviour and regain control over the situation, they need to put something like devpi or pydist in place.
On a personal note, I wonder if maybe we should look at all features/issues such as these in a different light:
Either it is somewhat of a "false claim" (a promise that can not be kept, due to the already existing ecosystem). Or poetry could double down on that, double check that the prioritization of indexes works as intended and sell it as an advantage over other tools (pip, etc.). |
@sinoroc if I understand correctly the PR introducing
so if installer logic is already on the Poetry side, then, I guess, it can claim it ensures the precedence. |
I link python-poetry/poetry#3477 as somewhat related. |
@abn sorry, flag --without-indexes already implemented? I need to get requirements without index-url |
It seems that settings from
Should create a
|
Closing as wontfix given that this is a limitation of the format and not up to Poetry. @henrytseng's issue is different and already fixed. |
-vvv
option).Issue
This issue is a follow-up to the problem identified in python-poetry/poetry#3238:
@abn has already confirmed the validity of the issue, but also provided one concern:
So we also have to consider how to introduce such a change not to break any existing workflows.
The text was updated successfully, but these errors were encountered: