Add "provides" package metadata. #194
Conversation
| self._packages_by_name_[package.name].append(package) | ||
| for constraints in package.provides: | ||
| req = Requirement.from_constraints(constraints) | ||
| assert not req.has_any_version_constraint |
There was a problem hiding this comment.
Can you explain this assertion?
There was a problem hiding this comment.
Ah yes, I forgot to write about it. Really we need to move the entire package metadata spec into the docs here.
The long and short of it is that right now we don't have a good way to handle provides with version numbers. We might someday, but there aren't any good use-cases that I know of. This assertion is there to make sure package metadata authors haven't done that. It should probably be ValueError or InvalidConstraint or something instead. What do you think?
There was a problem hiding this comment.
This does sound like an InvalidConstraint. If this exception trickles up to users, we would want to make sure that the message was clear, too
|
Just a few questions |
| "install_requires (zope *, numpy ^= 1.8.0, requests >= 0.2)", | ||
| "conflicts (requests ^= 0.2.5, requests > 0.4, bokeh_git)", | ||
| "conflicts (requests ^= 0.2.5, requests > 0.4, bokeh)", | ||
| "provides (webplot ^= 0.1, bokeh)", |
There was a problem hiding this comment.
How is this different from "provides with version numbers"?
There was a problem hiding this comment.
This is only testing our ability to parse, which separates the clauses and builds constraint tuples, but doesn't validate. In general we don't validate things up front due to the overhead of parsing version objects and the sheer number of packages. Also, we will not be parsing pretty strings during a normal work flow. IThe program which is using simplesat as a library will construct package metadata directly (which is why we guard against it below this level).
Raise InvalidCosntraint instead of AssertionError
|
LGTM |
This adds
PackageMetadata.providesand the associated code around that. It works by dumping all of the providers of a given name into pool's the internalname_to_packageslist. The rest of the behavior falls out from that.If package A
providespackage B, then either A or B can be used to satisfy dependencies (or cause conflicts with) B. This does imply that package A replaces package B or that package B is somehow obsolete or that package A should be preferred. With the current implementation, if two packages provide the same thing then you'll get whichever has a higher version number, but this is unspecified. If you care about priority, you'll need to use some of the other metadata features (not yet implemented).See #177