Package versioning

[Jack Firth]

For a given package `foo`, the general idea regarding new changes that as I've understood it is:

1. Changes to existing functionality that break things belong in a new package `foo2` that provides differently named modules/collections from `foo`, since it's essentially completely different behavior. This allows both `foo` and `foo2` to be installed at once, such that code using the old package can coexist with code using the new one. This also means unless you explicitly choose to use the changed functionality by requiring `foo2`, your code won't break, and you can selectively upgrade parts of a codebase to use `foo2` instead of having to upgrade the whole shebang at once.
2. New features should up the version number in the package's `info.rkt`. This means different package sources for the same package name can declare which features are available, and client code can define a minimum set of features it requires.
   
3. Bug fixes and other changes to existing functionality that don't break things for well-behaved clients (for some reasonable definition of "doesn't break things" and "well-behaved clients") don't really need to update the package's `info.rkt`, but it would be a good idea if they did. They should increase the version number less than new features do (e.g. 1.0 -> 1.1 instead of 1.0 -> 2.0). This gives more flexibility to client code feature specification, a client package can say "I really want 1.0, but it has a bug in it that wouldn't be fixed until 2.0, but 2.0 has features I don't need".
   
4. For packages whose name includes the author name, e.g. "jack-mock", or for modules or collections in the "unstable" collection, all bets are off. Existing functionality may change without warning, new stuff could be added, old stuff could be removed, multiple times a day. This gives package authors ways to experiment with published code while warning clients of experimental behavior.

At least, this is how I've been attempting to do things recently. It seems like a pretty reasonable way of working. The biggest problem thus far with this workflow is that if a package `foo` says "I require version 2.0 of package X", the package catalog can only give you the most recent version of package X. This isn't a major issue if package X is well-behaved regarding backwards compatibility, but as these are social rules and not technical ones, outliers will exist. The "safest" thing for installation to do would be to install version 2.0, as it's the closest match to the features required by `foo`.

In order to support this, would it make sense for the package X to have something like this in it's info.rkt?

(define version-sources
  (hash "1.0" package-source-for-foo-1.0
        "1.1" package-source-for-foo-1.1
        "2.0" package-source-for-foo-2.0))

I think it would be possible for the package catalog and package build server to use this information to figure out what to do with requests for a particular version of a package name. I don't know enough about the implementation of that infrastructure to know how feasible this is however.

What are some alternate ways of versioning packages? Should this process be documented and referenced by the package catalog website? Or the main racket documentation on packages?

[Alexis King]

The frustrating thing about this problem is that it is a problem that seems to be fundamentally *solved*. PLaneT didn’t do it quite right, it’s true, but the current package system doesn’t, either. In fact, in a number of ways, the new system is catastrophically worse than the old one (it doesn’t scale).

I’ve ranted about this plenty already, but most people seem unconvinced about why this is such a massive problem. I maintain that it is. With a little bit more knowledge on this topic, let me express precisely why the current system does not work.

In this conversation, two people touched upon points that I think are important.

First, from Neil:
> My super-strongly preferred engineering notion: backward-compatibility of a package refers to the *documented* behavior of the package, not to actual behavior.

Second, from Jack:

> The biggest problem thus far with this workflow is that if a package `foo` says "I require version 2.0 of package X", the package catalog can only give you the most recent version of package X. This isn't a major issue if package X is well-behaved regarding backwards compatibility, but as these are social rules and not technical ones, outliers will exist.

These are both incredibly flawed. They might work fine in a tiny little academic environment, but in the real world, this is almost outlandish for a few reasons:

1. Things that are “just bugfixes” will inevitably break things every once
in a while.
2. If a library has a bug, sometimes the only way to deal with it is to
hack around the bug. When the bug is fixed, the hack might break.
Broken code!
3. Asking people to make a new package for every breaking change they
introduce (1) introduces a large barrier to package developers and (2)
will lead to a massively cluttered set of packages with no semantic
clarity about the differences. Packages foo12 and foo13 might have tiny
incompatibilities, but foo13 and foo14 might be whole rewrites.

This can be solved with tooling, fortunately. However, it does mean that, under the current model, every new version of a package will need to be a distinct “package” under the current system’s definition of “package”.

So what’s the right way to do it?

1. Use semantic versioning to version packages and to resolve
dependencies. This works, but it still has the social problem, so…
2. Introduce a dependency “lockfile” the way Ruby’s Bundler tool does.
This means that dependencies won’t change unless a user explicitly
updates them, but updating to a new version is still painless because
semantic versioning makes it clear.
3. Make this the only user-facing interface. Either scrap the current
system or make it an internal component of a larger system.

I’ve actually taken some small stabs at implementing something like this, but it’s a nontrivial project, especially since the current package server’s API seems to be undocumented (I’m referring to the API the JS uses, not the interface raco uses). Plus I’d be on my own, and so far people don’t seem to care much about fixing this. Perhaps I’m wrong and it’s not as big of a problem as I think.

Alexis

(As an aside, the ability to introduce breaking changes into an API without fear of breaking everyone’s code is incredibly powerful for a package maintainer. It’s mostly why the iteration speed in JS-land can be so blindingly fast, but everyone still hangs together. There are problems with that example, specifically, but working on Racket packages feels like walking on eggshells in comparison.)

[Neil Van Dyke]

Alexis King wrote on 09/01/2015 06:58 PM:
> First, from Neil:
>> My super-strongly preferred engineering notion: backward-compatibility of a package refers to the *documented* behavior of the package, not to actual behavior.

> These are both incredibly flawed. They might work fine in a tiny little academic environment, but in the real world, this is almost outlandish for a few reasons:

My intent was to emphasize the documentation first. I allude in
subsequent sentences to exceptions and such, but I want people to start
by thinking about documented behavior&interfaces as the basis for
reusing modules. Because I think not everyone is.

When people start using the term "social", I fear some might be
imagining some magical open-office pair-programming free-love
marijuana-smoking drum-circle up-voting utopia, in which all problems
are solved most effectively through free-spirited communication, not by
employing engineering skill and smart collaboration practices.

BTW, I think the "tiny little academic environment" charge is off. I
suspect I have as much varied industry experience as almost anyone on
this list. I'm speaking of real industry dynamics, and of models that I
think are viable for adoption by some real industry developers. I have
existence proofs.

> Perhaps I’m wrong and it’s not as big of a problem as I think.

I agree that there is work to be done, at least for my needs. At one
point, in earlier development of the package system, I was harsh and
rude about some concerns, which I regret. My goal is to work
within/atop the accepted system.

Neil V.

[Matthew Flatt]

At Tue, 1 Sep 2015 15:58:44 -0700, Alexis King wrote:
> I’ve actually taken some small stabs at implementing something like
> this,

Great!

> but it’s a nontrivial project

That's almost certainly true.

> especially since the current
> package server’s API seems to be undocumented (I’m referring to the
> API the JS uses, not the interface raco uses)

I can't comment much on that, except to say that the package server is
kind of its own thing by design, and so that part is likely more fluid
and easier to change as you see fit.

> Plus I’d be on my own,

NO!

Take a bigger stab. Post code. Submit pull requests.

[Alexis King]

> Take a bigger stab. Post code. Submit pull requests.

It’s on my list of Racket projects to work on! ;) My recent updates to my Heroku buildpack and my release of my environment variable manager actually came out of working with the web server. I’m playing with it, but I haven’t gotten very far... yet.

To comment on the existing package server, specifically: I’m not yet sure if it’s possible to build what I want on top of it, but it’s sufficient for 90% of the functionality. It would be great to have access to that so I don’t have to reinvent the wheel (which would likely take more time than actually implementing some of the features on top).

But you’re right. My recurring rants about this have mostly been in hope to get people worked up about something, but I don’t have much code to show for it at this point. All in time...

[Robby Findler]

I too think it would be fantastic if you took this on. 

Robby 

--
You received this message because you are subscribed to the Google Groups "Racket Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
To post to this group, send email to racke...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/4407870D-65CD-46BF-84C4-C03900AB739A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Jack Firth]

I've also been working on some package server stuff, can I point you to it? In particular there's work there that makes package catalogs first class citizens, documenting the available routes for uploading and modifying packages, and stuff like that. It's buried in my docker-racket-catalog repo, but I would be more than happy to pull it out into a separate package.

[Jack Firth]

(Sorry for double post, forgot to respond to another point)

Regarding using semantic version to resolve correct dependencies: what do you do when a codebase needs two different versions of a package? Suppose your app depends on packages A and B, but both A and B depend on C. More specifically, they depend on different versions of C. Under the current system, assuming a package and it's clients are "well behaved", either A and B both depend on C without problems, or either A or B depends on C2, which installs different collections than C.

This can be fixed by allowing multiple versions of a collection to be simultaneously installed, but that feels really tricky. Additionally it does nothing about a single module that depends on both C and C2. I feel like the best advantage of the current system is if there's breaking changes to C, I can say my package depends on both C and C2, and then selectively update individual pieces of code in my package. If I want to completely move to C2, then I just remove the dependency on C and look for broken things. Whatever happens moving forward, I'm interested in keeping that feature.

[Jay McCarthy]

On Tue, Sep 1, 2015 at 2:23 PM, Jack Firth <jackh...@gmail.com> wrote:
> In order to support this, would it make sense for the package X to have
> something like this in it's info.rkt?
>
> (define version-sources
> (hash "1.0" package-source-for-foo-1.0
> "1.1" package-source-for-foo-1.1
> "2.0" package-source-for-foo-2.0))
>
> I think it would be possible for the package catalog and package build
> server to use this information to figure out what to do with requests for a
> particular version of a package name. I don't know enough about the
> implementation of that infrastructure to know how feasible this is however.

This is an interesting idea and I'd be curious how a patch that
implemented it would look.

One thing that would be difficult, I expect, is that presently
packages never mention their own sources or the sources of other
packages, typically. This facilitates new implementations of the same
interfaces and controlling what code you have installed by freezing an
old catalog.

I think what you really might want is another tool for building a
catalog. If you are currently happy with a release of a package you
have, you can freeze the checksum and get the same checkout on another
computer, rather than reinstalling and getting the latest release.

It's conceivable that the package info lookup API with the catalog
could include "I want version X", but because new versions are defined
to be backwards compatible, as long as the server has some version
that's after X, then there is no reason to know what any old version
has, since any client should be happy with any release >X.

Jay

--
Jay McCarthy
http://jeapostrophe.github.io

"Wherefore, be not weary in well-doing,
for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
- D&C 64:33

[Jay McCarthy]

On Tue, Sep 1, 2015 at 6:58 PM, Alexis King <lexi....@gmail.com> wrote:
> The frustrating thing about this problem is that it is a problem that seems to be fundamentally *solved*. PLaneT didn’t do it quite right, it’s true, but the current package system doesn’t, either. In fact, in a number of ways, the new system is catastrophically worse than the old one (it doesn’t scale).
>
> I’ve ranted about this plenty already, but most people seem unconvinced about why this is such a massive problem. I maintain that it is. With a little bit more knowledge on this topic, let me express precisely why the current system does not work.
>
> In this conversation, two people touched upon points that I think are important.
>
> First, from Neil:
>> My super-strongly preferred engineering notion: backward-compatibility of a package refers to the *documented* behavior of the package, not to actual behavior.
>
> Second, from Jack:
>> The biggest problem thus far with this workflow is that if a package `foo` says "I require version 2.0 of package X", the package catalog can only give you the most recent version of package X. This isn't a major issue if package X is well-behaved regarding backwards compatibility, but as these are social rules and not technical ones, outliers will exist.
>
> These are both incredibly flawed. They might work fine in a tiny little academic environment, but in the real world, this is almost outlandish for a few reasons:
>
> 1. Things that are “just bugfixes” will inevitably break things every once
> in a while.
> 2. If a library has a bug, sometimes the only way to deal with it is to
> hack around the bug. When the bug is fixed, the hack might break.
> Broken code!
> 3. Asking people to make a new package for every breaking change they
> introduce (1) introduces a large barrier to package developers and (2)
> will lead to a massively cluttered set of packages with no semantic
> clarity about the differences. Packages foo12 and foo13 might have tiny
> incompatibilities, but foo13 and foo14 might be whole rewrites.

Another lesson is that developers of code that lots of people rely on
should seriously reconsider when they want to introduce breaking
changes. And for authors of code that very few people rely on, they
could explicitly work with them to help update their code. These two
patterns are what the long-term Racket developers have pursued.

> This can be solved with tooling, fortunately. However, it does mean that, under the current model, every new version of a package will need to be a distinct “package” under the current system’s definition of “package”.
>
> So what’s the right way to do it?
>
> 1. Use semantic versioning to version packages and to resolve
> dependencies. This works, but it still has the social problem, so…
> 2. Introduce a dependency “lockfile” the way Ruby’s Bundler tool does.
> This means that dependencies won’t change unless a user explicitly
> updates them, but updating to a new version is still painless because
> semantic versioning makes it clear.
> 3. Make this the only user-facing interface. Either scrap the current
> system or make it an internal component of a larger system.

I've said since the beginning that I think the package system supports
being a component in a PLaneT-like meta-package system. I think you
should work on it if you see it as a crucial problem. Let me know how
I can help!

> I’ve actually taken some small stabs at implementing something like this, but it’s a nontrivial project, especially since the current package server’s API seems to be undocumented (I’m referring to the API the JS uses, not the interface raco uses). Plus I’d be on my own, and so far people don’t seem to care much about fixing this. Perhaps I’m wrong and it’s not as big of a problem as I think.
>

Regarding the API that the JS uses, the server implementation is less
than 500 lines and is open-source:

https://github.com/racket/pkg-index/blob/master/official/dynamic.rkt

If you look at line 428, you'll see the 11 API calls:

[("jsonp" "authenticate") jsonp/authenticate]
[("jsonp" "update") jsonp/update]
[("jsonp" "package" "del") jsonp/package/del]
[("jsonp" "package" "modify") jsonp/package/modify]
[("jsonp" "package" "version" "add") jsonp/package/version/add]
[("jsonp" "package" "version" "del") jsonp/package/version/del]
[("jsonp" "package" "tag" "add") jsonp/package/tag/add]
[("jsonp" "package" "tag" "del") jsonp/package/tag/del]
[("jsonp" "package" "author" "add") jsonp/package/author/add]
[("jsonp" "package" "author" "del") jsonp/package/author/del]
[("jsonp" "package" "curate") jsonp/package/curate]

Each implementation starts with a simple hash table naming the arguments:

(jsonp/package/version/add
['pkg pkg]
['version version]
['source source])

If there were another client, I would be happy to accept a patch
documenting and committing to the API.

Jay

> Alexis
>
> (As an aside, the ability to introduce breaking changes into an API without fear of breaking everyone’s code is incredibly powerful for a package maintainer. It’s mostly why the iteration speed in JS-land can be so blindingly fast, but everyone still hangs together. There are problems with that example, specifically, but working on Racket packages feels like walking on eggshells in comparison.)
>

> --
> You received this message because you are subscribed to the Google Groups "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/60656584-93BE-412D-B46E-64A26943B78E%40gmail.com.

> For more options, visit https://groups.google.com/d/optout.

[Jay McCarthy]

Part of the design of the package system was explicitly allowing code
to use multiple copies of the same author's work, similar to how you
to here as C and C2. So, I'm glad you recognize that :)

Jay

> --
> You received this message because you are subscribed to the Google Groups
> "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/racket-dev/35130451-7119-4612-bd10-092515ce7ec9%40googlegroups.com.

[Jack Firth]

It's conceivable that the package info lookup API with the catalog
could include "I want version X", but because new versions are defined
to be backwards compatible, as long as the server has some version
that's after X, then there is no reason to know what any old version
has, since any client should be happy with any release >X.

There will be packages that aren't backwards compatible however. A simple bug fix could break a workaround in another package, and a rearranging of the internals of the package's collections could break packages depending on the private implementation of the collections. One person's non-breaking change may be another person's breaking change. This is going to happen, there's no way to completely prevent it. What do we do when that happens? It seems problematic to me if there's no easy way for package clients to lock themselves into a particular version and rely on the package catalog to guarantee they won't get anything else.

[Alexander D. Knauth]

To do that, you can put the package source for the specific version (instead of the name) in the deps specification, and if the package isn't already installed, it goes to that package source instead of through the catalog. That doesn't work if the user already has the newer version installed though, because it would just assume the newer version will work.

[Jack Firth]

To do that, you can put the package source for the specific version (instead of the name) in the deps specification, and if the package isn't already installed, it goes to that package source instead of through the catalog. That doesn't work if the user already has the newer version installed though, because it would just assume the newer version will work.

That seems like it could do as a workaround, but handling versioning shouldn't require going around the package catalog completely.

[Alexis King]

> To do that, you can put the package source for the specific version (instead of the name) in the deps specification, and if the package isn't already installed, it goes to that package source instead of through the catalog. That doesn't work if the user already has the newer version installed though, because it would just assume the newer version will work.

Yeah, that’s effectively negating all the benefits of a package system altogether.

[Jay McCarthy]

Package catalogs do not generally store any code, merely references to
other people's code. There's no way they can guarantee that old
tar-balls are still around. You can easily lock yourself in to a
specific version by using the `raco pkg catalog-copy/catalog-archive`
commands and distributing/saving the resulting catalog.

[Greg Hendershott]

The following may seem like a random feature request. But it does
relate to dependencies and backward compatibility. (And as long as
people are talking about enhancing, and/or layering something on top
of, the existing package system....)

Licenses.

Licenses determine what packages you may depend on.

And a change in licenses is potentially a significant form of backward
incompatibility.

1. I'd like packages to have meta-data about their license.

2. I'd like raco pkg to warn (by default; could be disabled) if missing.

3. Ideally there'd be some UID for each common license. Making it
simple to filter while searching for packages.

Even if there were UIDs for only a half dozen common ones -- such as
"none", "explicitly public domain", "LGPL", "GPL", and "MIT" -- that
would be helpful.

4. Really ideally? There'd also be some taxonomy/rules about
compatibility. Making it simple to search for "packages I can use
when my project uses license X". And also, to do a transitive check,
and point out any problems.

Even though the compatibility rules ought to have a big IANAL
disclaimer, it would be a helpful head-start on flagging things that
probably do or do not need AL's attention.

----

Do any other package systems do this?

Does someone else already maintain the IDs and rules in 3 and 4?

----

Maybe this is the sort of thing that could be handled "socially"? OTOH
we welcome assistance with other kinds of dependency checking.

Maybe this is a solution in search of a problem, today? OTOH as the
number of packages grows, and given how frequently people forget to
supply any license....

[Neil Van Dyke]

Greg Hendershott wrote on 09/03/2015 11:49 AM:
> 1. I'd like packages to have meta-data about their license.

Agreed. McFly did this, and the license metadata was included in the
generated documentation. Example: "http://www.neilvandyke.org/racket-csv/".

(Incidentially, you can see in the History section of that page that I
changed the license from LGPLv2.x to LGPLv3 perhaps too sneakily in
version 0.7.)

Even if the tools don't do much with the metadata yet, getting (correct)
metadata into packages early and often is good.

Neil V.

[Robby Findler]

This makes a lot of sense to me too. And a nice value-add for Racket!

> --
> You received this message because you are subscribed to the Google Groups "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAGspUn3YzeEjnuFSspxg8ak4UkCZM-eU3mJP-vi47sFKJ_Xo4A%40mail.gmail.com.

[Jack Firth]

Package catalogs do not generally store any code, merely references to
other people's code. There's no way they can guarantee that old
tar-balls are still around. You can easily lock yourself in to a
specific version by using the `raco pkg catalog-copy/catalog-archive`
commands and distributing/saving the resulting catalog.

They don't have to guarantee tar balls of the package at arbitrary points in time are around. They do have to guarantee that they have some understanding of multiple sources for a single package name, each with a different version. Locking yourself to a built package is a lot different than locking yourself to any package a catalog claims has the correct name and version. There is a pressing need for this, and it'll get much more pressing as the number of package users increases.

[Jack Firth]

Licenses are also a brilliant idea and hooking them into Scribble would be incredibly useful. Ideally I'd just like to write this in my scribble docs:

@license[MIT]

And have the package catalog, the documentation, etc. etc. all take care of displaying the license information.

[m...@mbtype.com]

Speaking as a lawyer (i.e., someone who always reads licenses, at whatever cost to my brain cells) I agree it would be nice to surface this information within the package system, much like dependencies or documentation. 

But speaking as a package developer, the idea that the package system could have heuristics to determine “compatible” licenses is sticky as molasses. Let’s suppose someone violates the heck out of my license. “But the package system said I could!” So who’s responsible — the licensee or the package system? 

Ultimately, responsibility for adhering to a license rests on the licensee. Thus, making it easy to make informed choices: good; making it easy to evade responsibility: not so good.

[Neil Van Dyke]

m...@mbtype.com wrote on 09/07/2015 01:47 PM:
> Speaking as a lawyer (i.e., someone who always reads licenses, at
> whatever cost to my brain cells) I agree it would be nice to surface
> this information within the package system, much like dependencies or
> documentation.
>
> But speaking as a package developer, the idea that the package system
> could have heuristics to determine “compatible” licenses is sticky as
> molasses. Let’s suppose someone violates the heck out of my license.
> “But the package system said I could!” So who’s responsible — the
> licensee or the package system?
>
> Ultimately, responsibility for adhering to a license rests on the
> licensee. Thus, making it easy to make informed choices: good; making
> it easy to evade responsibility: not so good.

I think this is an excellent and important point.

Some metadata encoding of popular licenses is good. But any checking by
the system should be very conservative in its logic, as well as very
conservative in any arguably-reasonable expectations to which that any
such checking might reasonably lead.

One thing that would be very useful is a dump of all the transitive
package dependencies and their dependencies, for human interpretation.
Note that, right now, such dumps are specific to version resolution
(e.g., version 1.0.1 of a package might depend on package "foo", but
version 1.0.2 instead depends on package "bar", with cascading
implications).

Another thing that might *eventually* become useful is programmatic
constraints by systems and/or packages. For example, let's say that
you're coding to the documentation of package "bleep", which you see is
documented as LGPLv3, but it might depend on packages you don't know
about, and the license of one of those packages might be be (or be
changed to) "GPLv3" without your knowledge. You might want to specify
in the metadata for your system the licenses for third-party packages
that you'll permit. Similarly, the package author of "bleep" might want
to similarly restrict the licenses of direct&indirect dependencies
(though we don't put that legal burden on the author of "bleep").
Separately, the author of GPLv3 package "xyzzy" might want to encode
that the package can only *used by* GPLv3+ packages. (I started this
paragraph by saying "eventually". I sugggest not going too far with
this just yet, because there are other complications I didn't get into,
and it's potential over-engineering territory, and easy to hit the wrong
balance before there is more real-world experience. I just wanted to
suggest the possibility, for any implications for how we think about
license metadata today.)

Neil V.

[Greg Hendershott]

I think it would be a big improvement over the status quo, even if the
only rule were dumb, simple equality: "Check whether all these
packages use the exact same license."

Even just that would probably help most of the people most of the time?


Mixing licenses, yeah I don't really know. I want to believe it would
be possible to help people get an approximately better understanding.
Maybe along the lines of:

http://creativecommons.org/choose/

Of course yes that comes with a "no legal advice" disclaimer in section 4 of:

http://creativecommons.org/terms

Regardless, I think there's a lot of space between the extremes of
ignorance and professional expertise. In that wide space, anything
that increases comprehension or even minimal awareness is helpful, I
think.

But I realize anything behind a simple license equality check is
beyond the scope of Racket, and is a job for some other organization.

[Robby Findler]

Maybe the right thing is to just collect the set of licenses of all
dependencies of a given pkg as an alternative view of some pkg, and
then you could navigate around yourself to make decisions?

Robby

> --
> You received this message because you are subscribed to the Google Groups "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAGspUn2j74%3D4o_N2YeoiWx%3DOdrcaKYobeoTdNbp5pKxfZOn3Rg%40mail.gmail.com.

[Laurent]

On 10 Sep 2015 10:46 pm, "Robby Findler" <ro...@eecs.northwestern.edu> wrote:
>
> Maybe the right thing is to just collect the set of licenses of all
> dependencies of a given pkg as an alternative view of some pkg, and
> then you could navigate around yourself to make decisions?

+1 to that. Help the user get the relevant information and let him make the tough choices.

> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAL3TdOPys-r3px8bA4iEEPMBvAO8xM1QrrUNv%3DK9MSoqaiJMgA%40mail.gmail.com.