Write relative find-links opts to output file#453
Write relative find-links opts to output file#453suutari-ai wants to merge 1 commit intojazzband:masterfrom
Conversation
481b410 to
40676ef
Compare
Add entry about merged PR jazzband#453.
If input file or command line has `--find-links` options that point to directories which are relative to the destination file (i.e. relative path from destination directory to find-links directory does not contain any `../` components), then those should be written to the output file. Now `--find-links` options in the source file work similarly as e.g. the `--extra-index-url` options. This makes it possible to make deploy scripts to install from `requirements.txt` without knowing about the find-links options.
|
This is also rebased onto master now. Any reviewers? This feature will be useful with the feature implemented in PR #464. |
| dst_dir = os.path.dirname(self.dst_file) | ||
| for abs_link in self.find_links: | ||
| rel_link = os.path.relpath(abs_link, start=dst_dir) | ||
| if not rel_link.startswith(os.path.pardir + os.path.sep): |
There was a problem hiding this comment.
Let's assume that user has /app/stuff/requirements.txt and /app/links/. In that case relative link would be ../links and this link will be omitted. Do you think it's okay?
|
This idea of using relative paths for find-link paths I'd like to see a little more discussion just to confirm that's the best behavior for users, rather than being dependent on the user-provided forms of the paths in some way. I don't often use the option myself so can't offer much insight, but I'd imagine there are cases where a relative path is desired but the above condition doesn't hold. I don't see a relevant issue open (or closed) about this, but please link it if I missed one. I think if we can get #1329 reviewed and settled, we should then try to establish a consensus on proper path behavior for find-links. |
|
I came here from the "pip-compile absolute links when given relative path" issue. In my opinion, I expect that different people will want different behaviours for relative paths and such. It is unlikely in my opinion, that you can provide a single sane default behaviour, that satisfies everyone. Currently, (at least for I would propose introducing some way to explicitly specify the desired behaviour. Something along the lines of in More importantly, this would also introduce a generic way to specify behaviour in ambiguous cases. TL;DR: Instead of trying to come up with some convoluted "clever" logic for automagically choosing the "correct" behaviour, consider providing 1 fixed default behaviour and allowing the user to explicitly specify alternatives via |
|
Thanks! Can you bring some of that feedback (for non-find-links paths) to #1329, which is currently using a behavior different from what you describe, but does allow users to specify behavior via the form of path they provide (rather than a comment)? Please have a look there, and leave a note if you think a comment parsing system would be better than what's up for review. |
|
Closing as if this was not fixed in 4 years, I doubt it will ever be. |
If input file or command line has
--find-linksoptions that point to directories which are relative to the destination file (i.e. relative path from destination directory to find-links directory does not contain any../components), then those should be written to the output file.Now
--find-linksoptions in the source file work similarly as e.g. the--extra-index-urloptions. This makes it possible to make deploy scripts to install fromrequirements.txtwithout knowing about the find-links options.