You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.
Currently, the dep status table output only reports rules from the current/root project's Gopkg.toml, which can be quite misleading, especially as projects using dep start relying on each other. This simplistic implementation needs to be made more sophisticated - we need to look at the whole computed depgraph described in Gopkg.lock and collect all the constraint rules expressed on a given project, keeping track of which project they originate from.
For the table view (which is all that exists right now), we can still keep the constraint expression simple - just gps.Constraint.Intersect() everything together, and the final result is what's printed there. For any given dependency having multiple dependers, the solver guarantees that either a) all the intersections will work cleanly, b) there is an override for a dependency, or c) the lock is somehow invalid.
However, if it's not too much bother, the implementation of the above should still do the work of keeping track of which constraints emanate from which depender, as in the individual item mode - e.g. dep status github.com/foo/bar (this is not yet implemented at all) - will want to report these constraints separately.
This will be fairly involved, but i'm still labeling it help-wanted because the actual goal here is quite straightforward. That should make navigating the complexities easier.
The simplest approach is cheating, and may have unintended side effects. But, it's a lot easier:
Do a Solve() in order to get back a Solution. The solve must be set up in exactly the same way as it is in dep ensure.
Add a gps func that takes a Solution and a SourceManager, and returns some kind of type DependerMap map[ProjectRoot]Dependency (type names can be changed). This information can be extracted directly from the internal state of the solver, which is already embedded in returned Solutions.
This'll be fine as a stopgap. Eventually, as a later followup issue (or if someone wants to be really intrepid right up front) I'd recommend an approach more along these lines:
Create a new gps function that takes a Lock and returns a map[ProjectRoot]Manifest, with constraints only for those imports that are in packages that are actually used.
For each project in the lock, it should basically replicate what *solver.intersectConstraintsWithImports() does. In fact, it'd be ideal to split that method out into a standalone, unexported func that can be used by both the solver and this new func.
Add another new gps func that takes one of these map[ProjectRoot]Manifest and converts it into that same e.g. type DependerMap map[ProjectRoot]Dependency described above.
The text was updated successfully, but these errors were encountered:
Relevant TODO
Currently, the
dep status
table output only reports rules from the current/root project'sGopkg.toml
, which can be quite misleading, especially as projects using dep start relying on each other. This simplistic implementation needs to be made more sophisticated - we need to look at the whole computed depgraph described inGopkg.lock
and collect all the constraint rules expressed on a given project, keeping track of which project they originate from.For the table view (which is all that exists right now), we can still keep the constraint expression simple - just
gps.Constraint.Intersect()
everything together, and the final result is what's printed there. For any given dependency having multiple dependers, the solver guarantees that either a) all the intersections will work cleanly, b) there is an override for a dependency, or c) the lock is somehow invalid.However, if it's not too much bother, the implementation of the above should still do the work of keeping track of which constraints emanate from which depender, as in the individual item mode - e.g.
dep status github.com/foo/bar
(this is not yet implemented at all) - will want to report these constraints separately.This will be fairly involved, but i'm still labeling it
help-wanted
because the actual goal here is quite straightforward. That should make navigating the complexities easier.The simplest approach is cheating, and may have unintended side effects. But, it's a lot easier:
Solve()
in order to get back aSolution
. The solve must be set up in exactly the same way as it is indep ensure
.Solution
and aSourceManager
, and returns some kind oftype DependerMap map[ProjectRoot]Dependency
(type names can be changed). This information can be extracted directly from the internal state of the solver, which is already embedded in returnedSolution
s.This'll be fine as a stopgap. Eventually, as a later followup issue (or if someone wants to be really intrepid right up front) I'd recommend an approach more along these lines:
gps
function that takes aLock
and returns amap[ProjectRoot]Manifest
, with constraints only for those imports that are in packages that are actually used.*solver.intersectConstraintsWithImports()
does. In fact, it'd be ideal to split that method out into a standalone, unexported func that can be used by both the solver and this new func.map[ProjectRoot]Manifest
and converts it into that same e.g.type DependerMap map[ProjectRoot]Dependency
described above.The text was updated successfully, but these errors were encountered: