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

Support relative paths and regularize path handling and formatting #1650

Closed

Conversation

AndydeCleyre
Copy link
Contributor

@AndydeCleyre AndydeCleyre commented Jun 30, 2022

This replaces #1329, rebased with care on top of pip-tools 6.8.0.

Changelog-friendly one-liners:

  • Support relative paths in input files, as long as they lead with file:, <vcs>+file:, or ..
  • Relative paths in input files become relative paths in output files.
  • pip-compile will interpret relative paths in an input file as relative to that input file, rather than the current folder, if --read-relative-to-input is passed.
  • pip-compile will reconstruct relative req paths as relative to the output file, rather than the current folder, if --write-relative-to-output is passed.
  • pip-sync will interpret relative paths in an input file as relative to that input file, rather than the current folder, if --read-relative-to-input is passed.
  • Annotation paths are now relative to the output file.
  • Don't overwrite an input file ending in '.txt' when deriving the output file path.
  • Don't confuse dots in folder names with file extensions when deriving the output file path.
  • Include extras more reliably in output lines, like pkg[extra1,extra2].

Contributor checklist
  • Provided the tests for the changes.
  • Assure PR title is short, clear, and good to be included in the user-oriented changelog
Maintainer checklist
  • Assure one of these labels is present: backwards incompatible, feature, enhancement, deprecation, bug, dependency, docs or skip-changelog as they determine changelog listing.
  • Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

@AndydeCleyre AndydeCleyre force-pushed the feature/relpaths-post-6.8.0 branch 2 times, most recently from 0bdf7a7 to 07a2948 Compare July 18, 2022 15:49
@AndydeCleyre AndydeCleyre force-pushed the feature/relpaths-post-6.8.0 branch from 07a2948 to 3f9518a Compare August 15, 2022 14:09
@AndydeCleyre
Copy link
Contributor Author

I think the Windows-only testing is not properly updating the coverage report.

@ivanst0
Copy link

ivanst0 commented Sep 15, 2022

@AndydeCleyre, the lines that are showing as not covered anymore after this PR in Codecov report are hit only on Python 3.11. There is only a single job running under Python 3.11 and it failed to upload the coverage to Codecov.
Rerunning the checks should solve the problem.

Thank you for implementing this change!

@ssbarnea ssbarnea added the enhancement Improvements to functionality label Sep 15, 2022
Copy link
Member

@ssbarnea ssbarnea left a comment

Choose a reason for hiding this comment

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

LGTM but a second review should be done due to the size of the change.

@AndydeCleyre AndydeCleyre force-pushed the feature/relpaths-post-6.8.0 branch from 3f9518a to 8a43d1f Compare October 1, 2022 19:53
@AndydeCleyre
Copy link
Contributor Author

I'm just pushing periodic rebases, but I'm not making any changes.

If passed, it will attempt to relative-ize the resulting URL (if possible).

Add helper: fragment_string
Tests:

- abs_ireq_preserves_source_ireqs
- format_requirement_impossible_relative_path_becomes_absolute (Windows-only)

Also, ensure copy_install_requirement preserves our custom attributes.
Specifically ones which start like file:///C:/
Ensure source ireqs' comes_from attr is credited in annotations
This brings with it more involved string manipulation
If passed, from_dir will be used instead of CWD to interpret relative paths.

Special care is taken to guarantee _was_relative in the yielded ireqs,
if originally relative.

When calling format_requirement,
_was_relative's presence now determines what's passed as from_dir:
either CWD or None (None leads to an absolute path output)

For ths to work we also re-assign the _was_relative attr
to ireqs generated from candidates in the backtracking resolver.
With test, and needed changes:

- Use this flag to decide what to pass as from_dir to parse_requirements
- Add init param to OutputWriter: write_relative_to_output
- Add corresponding from_dir logic and use to OutputWriter._format_requirement
- Add test_write_relative_to_output which runs with the new flag both on and off
This ensures absolute intact paths for git+file: reqs
With test_sync_relative_path

If the reqs in the output were written relative to that output file
(pip-compile --write-relative-to-output), then it's wise for pip-sync
to interpret reqs it finds in there from the location of the output file.

This is now possible with pip-sync --read-relative-to-input.

To be clear: pip-sync's "input" is pip-compile's "output."
This fixes at least two problems, for which tests are added.
And add tests via parameterization
@AndydeCleyre AndydeCleyre force-pushed the feature/relpaths-post-6.8.0 branch from 8a43d1f to aa3ee0f Compare October 3, 2022 15:19
@AndydeCleyre
Copy link
Contributor Author

It seems the coverage upload fails very regularly. I wonder if anyone has interest in pursuing a change like this?

@webknjaz
Copy link
Member

webknjaz commented Oct 3, 2022

It seems the coverage upload fails very regularly. I wonder if anyone has interest in pursuing a change like this?

I don't think so, I keep using Codecov, and it worked well in the past years. There are bugs, of course, that get fixed (some — by me: https://github.com/codecov/uploader/issues?q=author%3Awebknjaz). But in any case, I'd first try to get to the root of the issue you're seeing before making such radical changes which may not improve things.
Also, if we do this, I'd still keep Codecov uploads (even with a disabled check), because it provides a nice coverage view.

That said, it's clear that some jobs may have failed to upload coverage. It is currently hard to easily find out which ones. So I'd strongly recommend to:

  1. Set up env-specific flags
  2. Update the coverage action to v3 (it's currently v1 which is deprecated and uses the ancient uploader)
  3. Audit the workflows for things that may need updating

re:3 — I've looked at https://github.com/jazzband/pip-tools/actions/runs/3175334504/jobs/5173249582#step:11:37 and was confused by it complaining about the actions/checkout action. So I scrolled up and, to my horror, saw it using the @master version. That branch has been deprecated in favor of @main over 2 years ago. Our setup currently uses the commit dated 13 Jul 2020 (HEAD of master). Having such a combination of old software versions could lead to the flakiness we're seeing now.

@allanlewis
Copy link

I've looked at https://github.com/jazzband/pip-tools/actions/runs/3175334504/jobs/5173249582#step:11:37 and was confused by it complaining about the actions/checkout action. So I scrolled up and, to my horror, saw it using the @master version. That branch has been deprecated in favor of @main over 2 years ago. Our setup currently uses the commit dated 13 Jul 2020 (HEAD of master). Having such a combination of old software versions could lead to the flakiness we're seeing now.

I noticed recently that Dependabot can now update your actions for you: https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot

@ssbarnea
Copy link
Member

ssbarnea commented Oct 4, 2022

Please don't disable codecov, it fails because is primatly because it is not properly tuned. There are solutions for each of its problems. For example, making it require a number of success uploads bit lower than total. For example 9/10, or 8/10. Making it prevent failing a build if upload fails. Setting a rounding threshold to prevent it from posting a regression due to rounding errors.

It is essential to be able to browse the diff with its web interface in order to allow us to spot if some branches are not covered, especially for bigger changes.

Also, I would not keep its report as "required" for merge. I think we can all look at it an make a decision if we are about to ignore it or not.

@webknjaz
Copy link
Member

webknjaz commented Oct 4, 2022

I noticed recently that Dependabot can now update your actions for you: docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot

Yes, for as long as you're pointing at a tag or a commit sha but not branch. FWIW I've already made a PR updating this stuff. Along with a few others.

@webknjaz
Copy link
Member

webknjaz commented Oct 4, 2022

Also, I would not keep its report as "required" for merge. I think we can all look at it an make a decision if we are about to ignore it or not.

It was never required, just red.

@webknjaz
Copy link
Member

webknjaz commented Oct 4, 2022

Copy link
Member

@atugushev atugushev left a comment

Choose a reason for hiding this comment

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

@AndydeCleyre

I've tried to review this many times, but every time I caught myself thinking, that these changes are too hacky and bring too much complexity to the codebase.

As far as I remember the initial intention was to preserve -e . in requirements.txt, but then everything started growing as a snowball at some point - annotations, pip-sync, new options and etc.

format_reqirements() now thrice bigger because of the from_dir and looks like it breaks principles of single responsibility.

parse_requirements() looks too hacky due to changing workdir and parsing requirements with catching InstallationError and parsing again without fragments.

Parsing fragments using regexps also no good.

Sorry, I cannot approve this for the reason in the first paragraph. I know how much energy you've invested into it and much appreciated it. I'd want to step back and rethink this PR. Probably split this into smaller chunks, I don't know, whether it would help. I'd rather not have this feature rather than maintain unreliable code.

@ssbarnea
Copy link
Member

ssbarnea commented Oct 6, 2022

Closing for the reasons mentioned by @atugushev - Please do not take it personally. I do not disagree with original idea but proposed implementation does touch too much code and adds undesired complexity. Maybe we could look into achieving this gradually with small/atomic changes, so we can slowly move the code-base towards the desired destination. Keep in mind that there are also other changes coming, so small changes will be less likely to conflict.

@ssbarnea ssbarnea closed this Oct 6, 2022
@AndydeCleyre
Copy link
Contributor Author

Thank you for giving it as much chance as you did. All I can say is that I did my best given the constraints of backward compatibility and making no changes to pip itself.

@leifwalsh
Copy link

I would like to see something like this happen, as it causes extraneous diffs when updating requirements.txt files in automation that runs in temp directories. I'm currently working around it by patching over the generated files in my automation.

@ssbarnea any chance you could recommend how to break this up into smaller chunks? I totally feel where you're coming from and would be willing to help work on those but I don't know the codebase well enough to know how to split it up.

@AndydeCleyre
Copy link
Contributor Author

FWIW these 29 commits are such that all tests pass at each step along the way, though not always fully covered by new tests at each step.

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

Successfully merging this pull request may close these issues.

7 participants