On 10 Sep 2015 10:46 pm, "Robby Findler"
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 inf
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
On Thu, Sep 10, 2015 at 3:10 PM, Greg Hendershott
wrote:
> I think it would be a big improvemen
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
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 d
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 coul
>
> 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
This makes a lot of sense to me too. And a nice value-add for Racket!
On Thu, Sep 3, 2015 at 10:49 AM, Greg Hendershott
wrote:
> 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 enhanc
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 Hi
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 Wed, Sep 2, 2015 at 2:17 PM, Jack Firth wrote:
>> 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 n
> 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 inst
>
> 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
On Sep 2, 2015, at 2:17 PM, Jack Firth wrote:
>
> 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
>
> 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, sin
On Tue, Sep 1, 2015 at 6:58 PM, Alexis King 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
On Tue, Sep 1, 2015 at 2:23 PM, Jack Firth 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" pack
I too think it would be fantastic if you took this on.
Robby
On Tuesday, September 1, 2015, Alexis King wrote:
> > 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 environm
> 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 f
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 referrin
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
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’
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 diffe
22 matches
Mail list logo
