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

fix: Parse multiple requirements from a poetry dependency #4179

Merged
merged 8 commits into from
Sep 7, 2021
Merged

fix: Parse multiple requirements from a poetry dependency #4179

merged 8 commits into from
Sep 7, 2021

Conversation

xlgmokha
Copy link
Contributor

Why is this needed?

Poetry projects can specify multiple requirements for a dependency.

e.g.

numpy = [
	{ version = "^1.19", python = "^3.6,<3.7" },
	{ version  = "^1.20", python = "^3.7" }]
scipy = [
	{ version = "^1.5", python = "^3.6,<3.7" },
	{ version = "^1.6.0", python = "^3.7" }
]

This change is needed to allow the parser to parse dependencies with multiple
requirements.

What does this do?

This change handles poetry dependencies with multiple requirements by looping
through each requirement specified for a dependency.

Type of change

  • Bug fix (non-breaking change which fixes an issue)

@xlgmokha xlgmokha marked this pull request as ready for review August 30, 2021 20:58
@xlgmokha xlgmokha requested a review from a team as a code owner August 30, 2021 20:58
@xlgmokha xlgmokha marked this pull request as draft September 1, 2021 21:12
@xlgmokha xlgmokha marked this pull request as ready for review September 1, 2021 22:37
# @param req can be an Array, Hash or String that represents the constraints for a dependency
def parse_requirements_from(req, type)
[req].flatten.compact.map do |requirement|
next if requirement.is_a?(Hash) && (UNSUPPORTED_DEPENDENCY_TYPES & requirement.keys).any?
Copy link
Member

Choose a reason for hiding this comment

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

Just double-checking, this is functionally the same as next if req.is_a?(Hash) && UNSUPPORTED_DEPENDENCY_TYPES.any? { |t| req.key?(t) } right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep. It's a set intersect operation.

irb(main):001:0> [1, 2, 3] & [2, 3]
=> [2, 3]
irb(main):002:0> [1, 3, 4] & [5, 6]
=> []

check_requirements(requirement)

{
requirement: requirement.is_a?(String) ? requirement : requirement["version"],
Copy link
Member

@jurre jurre Sep 7, 2021

Choose a reason for hiding this comment

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

Slightly paranoid that we might get something that's not a String but also does not respond to #[] in a way that we'd expect but since no tests break that might not be a concern. Should we handle the type of req more explicitly?

Totally fine to keep as is, just thinking out loud here, but I found the [req].flatten.compact.map do |requirement| a little hard to follow 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Slightly paranoid that we might get something that's not a String but also does not respond to #[] in a way that we'd expect but since no tests break that might not be a concern.

I think this is a valid concern. Matching on type signature feels icky to me. I feel like there's a missing abstraction/interface here but I'm not sure what that is.

Should we handle the type of req more explicitly?

I'm not against this idea. I worked on this issue during my on-call shift last week so I've lost some of the context due to mo's limited memory but I can circle back to this. I think I would prefer to ship this small change as is because there were some jobs failing with this issue so this would at least unblock those. WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

WDYT?

👍

Copy link
Member

@jurre jurre left a comment

Choose a reason for hiding this comment

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

Nice one! I slow-chatted in the review-comments about a possibility to make the code a little more explicit, but it's totally fine to keep as is.

@xlgmokha xlgmokha merged commit 5bd7096 into dependabot:main Sep 7, 2021
@xlgmokha xlgmokha deleted the pip-slo branch September 7, 2021 16:14
@xlgmokha xlgmokha mentioned this pull request Sep 7, 2021
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.

2 participants