Feature matrix for current package management and vendoring solutions?

[mathew murphy]

Has anyone assembled a feature matrix for current Go package managers?

This would (a) help people pick a current interim solution, and (b) help guide developers of solutions towards the features people might want.

mathew

[Dave Cheney]

I think there is one on the go wiki.

--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-package-manag...@googlegroups.com.
To post to this group, send email to go-package...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mathew]

I couldn't find one. The main page for package management tools seems to be
<https://github.com/golang/go/wiki/PackageManagementTools>
It only has incomplete lists of features for some of the tools.

I was hoping for something formatted like (say)
<https://en.wikipedia.org/wiki/Comparison_of_wiki_software#Features_1>

but for Go package managers.


mathew

[mathew murphy]

So is there any interest from others in assembling a feature matrix for package managers? It might be useful as far as providing a direction for standardization.

mathew

[Sam Boyer]

https://docs.google.com/document/d/19HNnqMsETTdwwQd0I0zq2rg1IrJtaoFEA1B1OpJGNUg/edit do the trick?

[Daniel Theophanes]

I made one for *go* package managers a while ago:

https://docs.google.com/document/d/1y4mYe8Sk9jCPze6AyygxrC7j1sqEgwAycezpaE6JnC8/edit?usp=sharing

[Matt Farina]

That last doc appears out of date or at least incomplete. For example, Glide isn't included.

Overall, I like the idea of comparing Go package managers but the features we should compare them on aren't entirely clear, yet.

I did create https://github.com/Masterminds/glide/wiki/Go-Package-Manager-Comparison which is very high level and only includes a few package managers. Obviously, keep in mind it's attached to Glide.

[mathew murphy]

On Friday, July 29, 2016 at 11:57:36 AM UTC-5, Matt Farina wrote:

Overall, I like the idea of comparing Go package managers but the features we should compare them on aren't entirely clear, yet.

Well, that's what I'd like to try and get some agreement on. Then we can maybe write up the list with some longer description, and ask the various package manager authors to tell us which features their tools support.

Features from Daniel Theophanes' document:

 - Written in Go

 - Cross platform (Windows & Unix)

 - Pinning/locking of package versions 

 - Vendoring mechanism used (store, GOPATH or rewrite)

 - No VCS required

 - List packages

 - Detect/prevent duplicates

 - Record package versions

 - Record VCS version

 - Inspect project for new/unpinned dependencies

Features I had looked for myself:

 - Additional config file format (DSL, YAML, JSON, none required, ...)

 - VCSs supported (Git, bzr, hg, ...)

 - Fetch and vendor package in one step

 - Detect unused packages and optionally delete

 - Update all packages from GOPATH

 - Update all packages from origin repositories

 - Can build projects without using the tool

 - Pinning/locking of package versions to commits

 - Pinning/locking of package versions to tags/semver

 - Package aliasing

 - Test coverage percentage

 - Documentation quality

Additional features from the Glide comparison:

 - Semver support

 - Semver range support

 - Dependency tree resolution including versions

 - Import from other package managers

 - Support for vendored or on-demand package versions

 - Repo aliasing

 - Plugin support/extensibility

 - Common range syntax (?)

I don't know what "common range syntax" really means. Do PHP and JavaScript use the same syntax as (say) RubyGems or Git, i.e. is there actually a consensus on this?

mathew

[Daniel Theophanes]

It was made over a year ago. So yeah, glide wasn't an option then.

[mhhcbon]

hi,

my 2 cents,

About those items

 - Test coverage percentage

 - Documentation quality

 - Detect unused packages and optionally delete (...them from the manifest file)

IMHO, Those items you are citing here would rather be provided by independents projects.
Thus the tool can focus on solving the one job it was assigned to.

About

 - Update all packages from GOPATH

Not sure about your meaning, i try my chance to get it right or wrong.
In some other programming language they d just symlink it.
Then, as you ll want your to share your lib, you ll have to publish that linked dependency, thus,
in your initial project, you d have to transform that link into a real dependence with its target version.

In fact, you really can t share a project using a dependency available only in your gopath.


About

 - Detect/prevent duplicates

To me this sounds duplicates with the very purpose of tree dependencies to resolve.


About

 - Package aliasing

Which use case for ? Fork ?
If so, and if the manifest have a package name, it could keep the upstream name,
thus when the dependency is stored on the local,
rather using the origin address (of the fork),
the tool could store it under its package name,
which in fact would resolve to the upstream package.
but maybe i got it wrong :)

[mathew murphy]

On Friday, July 29, 2016 at 3:15:21 PM UTC-5, mhhcbon wrote:

About those items

 - Test coverage percentage

 - Documentation quality

 - Detect unused packages and optionally delete (...them from the manifest file)

IMHO, Those items you are citing here would rather be provided by independents projects.

I think (hope!) you misunderstand. I mean "What percentage test coverage does the package manager have", and "How good is the documentation for the package manager".

I also see detection of unused packages (dead code) as a fundamental requirement. 

 

Thus the tool can focus on solving the one job it was assigned to.

About
 - Update all packages from GOPATH

Not sure about your meaning, i try my chance to get it right or wrong.

I mean update packages into the vendor/ directory by finding them in the GOPATH, as opposed to by downloading them from remote repositories.

 

In some other programming language they d just symlink it.

Whether it's done with symlinks, hardlinks or by actually copying files is an implementation detail.

 

 - Package aliasing

Which use case for ? Fork ?

Yes. Again, implementation details are a whole separate issue, but it's a reasonable thing to want to do I think.

mathew

[Sam Boyer]

On 7/29/16 17:04, mathew murphy wrote:
>
> On Friday, July 29, 2016 at 3:15:21 PM UTC-5, mhhcbon wrote:
>
> About those items
>
> - Test coverage percentage
> - Documentation quality
> - Detect unused packages and optionally delete (...them from the
> manifest file)
>
> IMHO, Those items you are citing here would rather be provided by
> independents projects.
>
>
> I think (hope!) you misunderstand. I mean "What percentage test coverage
> does the package manager have", and "How good is the documentation for
> the package manager".

Eek. I hope we're not elevating code coverage percentage to the level of
objective metric?

>
> I also see detection of unused packages (dead code) as a fundamental
> requirement.
>
>
> Thus the tool can focus on solving the one job it was assigned to.
>
> About
> - Update all packages from GOPATH
>
> Not sure about your meaning, i try my chance to get it right or wrong.
>
>
> I mean update packages into the vendor/ directory by finding them in the
> GOPATH, as opposed to by downloading them from remote repositories.

I see this raised a lot. It strikes me as just as much an implementation
detail as the next two items you raise. I think it's so common because
people feel like it's an obvious, adjacent optimization wrt how they
think about their GOPATH today.

IMO, though, it's a red herring today (to the extent that it's about
performance improvements, anyway). It's an implementation detail, like
the rest.

http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

>
>
> In some other programming language they d just symlink it.
>
>
> Whether it's done with symlinks, hardlinks or by actually copying files
> is an implementation detail.
>
>
> - Package aliasing
>
> Which use case for ? Fork ?
>
>
> Yes. Again, implementation details are a whole separate issue, but it's
> a reasonable thing to want to do I think.
>
>
> mathew
>

> --
> You received this message because you are subscribed to a topic in the

> Google Groups "Go Package Management" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/go-package-management/Qk_imqNu4ZY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> go-package-manag...@googlegroups.com
> <mailto:go-package-manag...@googlegroups.com>.

> To post to this group, send email to
> go-package...@googlegroups.com

> <mailto:go-package...@googlegroups.com>.

[Dave Cheney]

I don't see a great deal of value in trying to construct a solution from the intersection of the existing tools.

As Henry Ford quipped, "if I asked people what they wanted from a car, they would have told me they wanted a faster horse"

I see much more value in asking users what problems they are trying to overcome, by way of users stories.

Dave

You received this message because you are subscribed to the Google Groups "Go Package Management" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-package-manag...@googlegroups.com.

To post to this group, send email to go-package...@googlegroups.com.

[Edward Muller]

:+1:

I don't see much value in over analyzing existing solutions either in Go or outside of it.

I'm not saying we should ignore prior art though. Understanding it is important. I'm just wary of going down a path where we base every decision based on how only existing tools/solutions work.

[mhhcbon]

Hi

Le vendredi 29 juillet 2016 23:04:24 UTC+2, mathew murphy a écrit :

On Friday, July 29, 2016 at 3:15:21 PM UTC-5, mhhcbon wrote:

About those items

 - Test coverage percentage

 - Documentation quality

 - Detect unused packages and optionally delete (...them from the manifest file)

IMHO, Those items you are citing here would rather be provided by independents projects.

I think (hope!) you misunderstand. I mean "What percentage test coverage does the package manager have", and "How good is the documentation for the package manager".

I guess we just disagree  : )

 

I also see detection of unused packages (dead code) as a fundamental requirement. 

 

Thus the tool can focus on solving the one job it was assigned to.

About
 - Update all packages from GOPATH

Not sure about your meaning, i try my chance to get it right or wrong.

I mean update packages into the vendor/ directory by finding them in the GOPATH, as opposed to by downloading them from remote repositories.

 

I think it is bad practice because you are linking you project to a resource that may, or may not, be available to other they day you publish it.
But see next P for some case where a similar situation is welcomed.
 

In some other programming language they d just symlink it.

Whether it's done with symlinks, hardlinks or by actually copying files is an implementation detail.

 

...I guess you jumped to quickly on the symlink word to conclude of implementation details.
Because behind that in fact... (humble opinion)

there s the story of someone who is developing a project dependents on multiple small libraries and he would like to jump to the code right away rather than going through the setup phases, keeping that for later when everything is stabilized.

Or the story of one which update an existing project dependent on a lib B, both projects are tightly linked and he needs a sort of flexible way to develop both of them at a the same time before he publish them to their newest versions.

 - Package aliasing

Which use case for ? Fork ?

Yes. Again, implementation details are a whole separate issue, but it's a reasonable thing to want to do I think.

Yeah it s an interesting feature, i agree.

mathew

> I don't see a great deal of value in trying to construct a solution from the intersection of the existing tools. 

If i m correct, i d say its all about shaping a goal to not only implement a solution, but creates new workflow and behaviors about how we Go.

[mhhcbon]

how about,

- couple a package with its engine compatibility
- have two (three ?) sets of dependencies.
Package dependencies (what other piece of code i need to build this software)
Package dev dependencies (what other piece of code i need to test this software)
Build dependencies (?) (what other piece of code i need to build this software)

About the last one im unsure given Go, i m using rather simple build commands myself which crossplatform compatible. Are there case where this would be needed ?

[mathew]

On Fri, Jul 29, 2016 at 9:52 PM Sam Boyer <s...@samboyer.org> wrote:

Eek. I hope we're not elevating code coverage percentage to the level of
objective metric?

Clearly code coverage percentage *is* an objective metric. How *useful* a metric it is, and what it indicates, is another question. But I'd rather use a package manager with 80% code coverage over one with no unit tests at all, wouldn't you?

 

> I mean update packages into the vendor/ directory by finding them

> in the
> GOPATH, as opposed to by downloading them from remote 

> repositories.

I see this raised a lot. It strikes me as just as much an implementation
detail as the next two items you raise.

I think it's legitimate to want to update packages from a directory on your local disk. You could certainly choose to ignore GOPATH and specify the source some other way, but what would be the benefit?

mathew

[mathew]

On Fri, Jul 29, 2016 at 10:12 PM Dave Cheney <da...@cheney.net> wrote:

I don't see a great deal of value in trying to construct a solution from the intersection of the existing tools.

Nor do I. However, the existing tools have been built to solve people's problems, and looking at the features they have implemented can provide useful clues towards what those problems are.

Also, until a solution is constructed that meets all needs — assuming such a thing will ever happen — people will need to match up their requirements against one of the existing solutions in order to pick one to use in the interim. A comparison table can help with that process. That's why I originally started making my comparison table: I was annoyed by Godep, and wondered if there was something better. (I'm still wondering.)

mathew

[Sam Boyer]

On 7/30/16 09:44, mathew wrote:
> On Fri, Jul 29, 2016 at 9:52 PM Sam Boyer <s...@samboyer.org
> <mailto:s...@samboyer.org>> wrote:
>
> Eek. I hope we're not elevating code coverage percentage to the level of
> objective metric?
>
>
> Clearly code coverage percentage *is* an objective metric. How *useful*
> a metric it is, and what it indicates, is another question. But I'd
> rather use a package manager with 80% code coverage over one with no
> unit tests at all, wouldn't you?

Sorry, yes, "useful metric" is what I should have said.

If I were comparing two package managers that profess to work the same
way, make the same tradeoffs, allow the same outcomes, afford the same
choices to users, and both have been battle-tested in production, then
yes, I'd want the one with more test coverage.

...assuming that the test coverage was substantive. That is, was it just
covering the happy path? In a complex piece of software, the happy path
can often get you to >85% coverage. So, are the major points of
flexibility covered in all their combinations? And, since you bring up
unit tests in particular, what about behaviors that are dependent on
some preexisting state? What if some subpaths are covered with unit
tests, but different inputs end up recombining them in buggy ways?

Maybe you go a more sophisticated route - e.g. counting the number of
tests that cover a line, not merely whether the line is covered at all.
But then, what's "enough" coverage? Is it meaningful to add more?

IMO, none of these things have easy answers, and while they may seem
pedantic for simple programs, they become increasingly important for
complex ones.

Case in point: gps currently has around 60 test fixtures that describe a
unique input to the solver, plus the expected output (half-ish of those
are from a test bestiary I borrowed from dart's pub pkg mgr tool). I
could probably achieve the same level of test coverage by picking three
or four of them. But that would be garbage.

IMO, the risk of emphasizing code coverage at all is that it encourages
reductive thinking about a complex choice. I include the coverage badge
in gps' README because, IMO, coverage does do one thing well: it tells
*contributors*, "hey, we care about testing, and we could use some more
tests. These uncovered lines are the low-hanging fruit!"

>
> I think it's legitimate to want to update packages from a directory on
> your local disk. You could certainly choose to ignore GOPATH and specify
> the source some other way, but what would be the benefit?

Clarity.

There is no guarantee that what's on GOPATH represents meaningful choice
by the user.

On one end of the scale, code on GOPATH might be something go get
happened to grab one day as a dependency for some random thing the user
installed but has never even used. On the other, maybe it's part of a
suite of repositories the user hacks on every day, which the user
carefully keeps manually in sync. We do not know, and really cannot know.

So, if we run across an uncommitted file on GOPATH, should we copy it
in? What if there's a commit made locally, but it hasn't been pushed
upstream yet - is that OK to use? Is it OK to change what's on GOPATH to
a different version in order to copy it over? If so, should we change it
back when we're done? What if errors occur while doing so - how do we
recover?

GOPATH is, by design, a soup on which users are implicitly expected to
impose their own order (if any). And there are some important cases
being discussed where some non-arbitrary rules might be imposed on
GOPATH. But if our goal is to create a predictable, reliable tool, then
in the general case, GOPATH is an unsuitable foundation.