Re: [racket-dev] planet2 and versions

[David Vanderson]

On 12/13/2012 07:19 AM, Jay McCarthy wrote:

This is on my future plans to make a "raco pkg bundle" that will
produce a big tar ball that and can be installed on another machine
and get the same packages (even if they are no longer available at
their sources with those versions) installed. I just didn't prioritize
it for the beta release.

Jay



Cool.  Thanks very much!

Dave
_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] planet2 and versions

[Asumu Takikawa]

On 2012-12-13 08:17:32 -0700, Jay McCarthy wrote:
> Why aren't you just only using the development version?

This mainly comes up if I want to test the uploaded version to make sure
it works. I can probably figure out a better workflow though (such as
keeping around a release version of Racket to test released packages).

> As an aside in response to this whole thread, this is unbelievably
> frustrating because both of my first two proposals w.r.t Planet 2
> dealt with multiple versions, real dependency on the core (which P1
> didn't have), actual enforcement of public/private modules (something
> discussed on IRC yesterday), etc, and everyone hated that and said
> they wanted something simpler like what OSes give. Now we have that
> and people hate it. Argh.

FWIW, I don't hate Planet 2 and I appreciate the design and
implementation work you've done. I'll take Matthew's advice and submit
subsequent feedback as patches.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] planet2 and versions

[Sam Tobin-Hochstadt]

On Thu, Dec 13, 2012 at 10:08 AM, Jay McCarthy  wrote:
>
>> Finally, as a meta-point, is there any evidence that just throwing away
>> versions will work? Any precedents? So far, this seems like a classic case
>> of throwing the baby out with the bathwater: versions sometimes cause
>> problems... so we won't have them. Now we have the same problems but fewer
>> tools for handling them. (See also Eli's response.)
>
> Most OSes work like this because you can't install different versions
> of the same package. Yes, they have version numbers, but the only
> useful semantics of those is that the installed and the current
> version number aren't equal (so you need to update.) If you also allow
> Package A to depend on Package B's version X or above, then
> essentially you are allowing Package B to switch to Package B' at
> version X, because before that point it did something different. P2
> just makes that explicit.

I'm not certain about other OS-level package managers, but dpkg, the
one I know best, has more semantics than this.  In particular, you can
get situations where versions conflict, preventing you from upgrading
some package. The way this happens is that you can specify version
equality or maximum version constraints for dependencies, or conflicts
with other packages of specific versions. If I understand Planet2
correctly, you're always able to upgrade any particular package.

Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] planet2 and versions

[Matthew Flatt]

At Thu, 13 Dec 2012 08:17:32 -0700, Jay McCarthy wrote:
> As an aside in response to this whole thread, [...]

I recommend that further complaints and suggestions take the form of a
patch.

Creating a patch is more difficult, more time consuming, and you have
to understand even more details of Planet2... and all of that is more
or less the point, at this stage. We've had a long period of
speculation about the package system, and now we have something
concrete to try; further "discussion" on its design should be equally
concrete.

There's a possibility that, while working on actual code, you duplicate
work by someone else who has the same idea. That problem is nothing
new, though, as we have to deal with that in Racket development. Maybe
drop a note here to say that you have plans.

In that spirit:

I have in mind suggesting version checking and package name services
that can be version-specific, which I think will enable long-term
support for released versions with fairly small changes to the Planet2
implementation. I won't get a chance to try my suggestions until next
week, so no one who experiments in the next few days will conflict with
my attempts (and I'll be happy to abandon my plans if someone else gets
going first in a similar direction!).

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] planet2 and versions

[Jay McCarthy]

On Wed, Dec 12, 2012 at 11:48 PM, David Vanderson
 wrote:
> I was professionally writing Ruby code as that community struggled through
> package issues.  I hope that experience can shed some light here.  Also I'd
> like to understand the basic use cases and how they work in planet2.
>
> As a user, here are my 2 use cases:
>
> 1. My friend tells me about awesome library X, and I want to install it and
> use it.  Planet2 makes this easy.
>
> 2. I have an existing app running and I want to replicate it exactly
> somewhere else (including libraries).  I'm not sure this is possible with
> raw Planet2.  The Ruby community finally dealt with this by saving the full
> library dependency list in a file ("bundle", with version numbers) that you
> save alongside your app.  It works fairly well.

This is on my future plans to make a "raco pkg bundle" that will
produce a big tar ball that and can be installed on another machine
and get the same packages (even if they are no longer available at
their sources with those versions) installed. I just didn't prioritize
it for the beta release.

Jay

> Their experience suggests that accidental backwards incompatible changes in
> libraries happen frequently enough to need some kind of support for.
> Compatibility with the core language was not supported.  Either a library's
> webpage would say "requires ruby core >= 1.8.x", or sometimes importing the
> library would produce an error message telling you the same.
>
> Do these use cases make sense?  (I'd like to hear about library developer
> use cases, but I have no experience there)
>
> Thanks,
> Dave
>
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/dev



--
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] planet2 and versions

[Jay McCarthy]

On Wed, Dec 12, 2012 at 8:55 PM, Asumu Takikawa  wrote:
> On 2012-12-12 14:29:32 -0500, Ryan Culpepper wrote:
>> I'm trying to understand how things are supposed to work in planet2
>> without version information.
>
> Maybe this was discussed in the other (quite long) thread about Planet
> 2, but another thing that the lack of versions makes difficult is having
> both a development version of a package and a release version installed.
>
> That is, I find it useful to develop a package with a local link (e.g.,
> raco pkg install --link foo/). Eventually, I'll put up what I have on
> the central server. If I understand how things now work correctly,
> Planet 2 requires that I uninstall my local link and then install the
> uploaded package (since they have conflicting collections).
>
> If I subsequently work on my development version again, I have to
> manually uninstall and re-install the package. Doing this dance
> repeatedly is tedious.

Why aren't you just only using the development version?

As an aside in response to this whole thread, this is unbelievably
frustrating because both of my first two proposals w.r.t Planet 2
dealt with multiple versions, real dependency on the core (which P1
didn't have), actual enforcement of public/private modules (something
discussed on IRC yesterday), etc, and everyone hated that and said
they wanted something simpler like what OSes give. Now we have that
and people hate it. Argh.

Jay

--
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] planet2 and versions

[Jay McCarthy]

On Wed, Dec 12, 2012 at 4:01 PM, Ryan Culpepper  wrote:
> On 12/12/2012 03:58 PM, Jay McCarthy wrote:
>>
>> I agree with Carl.
>>
>> But I would make an even stronger suggestion, I would suggest that you
>> completely drop support for old Racket versions and if necessary
>> release "webapis-lts" and "scriblogify-lts" packages that conflict
>> with "webapis" and can only work on old versions. The LTS ones
>> wouldn't be included in the DrDr-tested collection of packages, but
>> the others would be. Casual users should upgrade and users with
>> serious version problems should upgrade slowly with only the LTS
>> versions.
>
>
> If I understand correctly, you are saying that non-LTS packages should
> ignore the recommendation of the FAQ (6.5, "package authors should not make
> backwards incompatible changes to packages").

I don't consider different versions of Racket as backwards incompatible changes.

> That doesn't sound like a good solution.
>
> If I want to support users running versions of Racket that are a couple
> releases old, it doesn't work.

Then it is your duty to not depend on new features of Racket and
Racket's responsibility to keep the old interfaces alive.

> If I want to depend on other packages, then in the absence of a standard
> approach I've got to trust that they have the same notions about
> compatibility and versions-encoded-as-package-names as I do. If I want to
> support Racket back to X.Y, I had better hope that the packages I depend on
> do too. That is, I'd have to figure out how each of them (and all of their
> dependencies) handle compatibility instead of just trusting that they all
> follow the single standard approach.
>
> Finally, as a meta-point, is there any evidence that just throwing away
> versions will work? Any precedents? So far, this seems like a classic case
> of throwing the baby out with the bathwater: versions sometimes cause
> problems... so we won't have them. Now we have the same problems but fewer
> tools for handling them. (See also Eli's response.)

Most OSes work like this because you can't install different versions
of the same package. Yes, they have version numbers, but the only
useful semantics of those is that the installed and the current
version number aren't equal (so you need to update.) If you also allow
Package A to depend on Package B's version X or above, then
essentially you are allowing Package B to switch to Package B' at
version X, because before that point it did something different. P2
just makes that explicit.

Jay

> If planet2 is aimed at a problem that is restricted in scope somehow that it
> doesn't need to worry about version issues, I still don't understand what
> that narrower problem is. If I'm supposed to think about planet2 as a way of
> distributing code, I'm still confused about what my obligations are when I
> create a package and what I can rely on from other packages.
>
> Ryan
>
>
>> I would also hope that P2's lack of an ability to depend on the core
>> version would induce better backwards and forwards compatibility from
>> Racket in the version.
>>
>> But I'm a bit radical on this front, so I assume that we will have a
>> robust alternative based on Carl's idea that uses P2 underneath it.
>>
>> Jay
>>
>> On Wed, Dec 12, 2012 at 1:13 PM, Carl Eastlund  wrote:
>>>
>>> I believe it is by design that Planet 2 does not resolve this kind of
>>> issue.
>>> This gives us room to experiment with different solutions without
>>> committing
>>> to one up-front, since Planet 1 ran into various limitations of its
>>> built-in
>>> policies.
>>>
>>> I will propose one possible solution for your "webapis" example.
>>> Distribute
>>> a primary wrapper package called "webapis" and separate specific versions
>>> such as "webapis1", "webapis2", and so forth.  Have the code in "webapis"
>>> determine at compile-time which specific version of webapis is
>>> appropriate
>>> for the current Racket version and install that package.  The specific
>>> packages would contain the actual code a client would import.  That way,
>>> installing the "webapis" package on any Racket version would install only
>>> the version of the implementation that works.
>>>
>>> I don't know if this is a complete solution, but it seems like a
>>> reasonable
>>> starting point.  As we figure out what patterns work, they themselves can
>>> be
>>> developed as reusable tools and built into their own packages.  I think
>>> this
>>> room for improvement will make Planet 2 a much better long-term model
>>> than
>>> Planet 1.  Of course we do eventually want a default system that package
>>> developers can use without too much mucking about with "experimental"
>>> versioning systems.  But I think an initial period of "crowd-sourcing"
>>> the
>>> design of that system will do us some good.
>>>
>>> Carl Eastlund
>>>
>>>
>>>
>>> On Wed, Dec 12, 2012 at 2:29 PM, Ryan Culpepper  wrote:


 I'm trying to understand how things are supposed to work in planet2
 without

Re: [racket-dev] planet2 and versions

[David Vanderson]

I was professionally writing Ruby code as that community struggled 
through package issues.  I hope that experience can shed some light 
here.  Also I'd like to understand the basic use cases and how they work 
in planet2.


As a user, here are my 2 use cases:

1. My friend tells me about awesome library X, and I want to install it 
and use it.  Planet2 makes this easy.


2. I have an existing app running and I want to replicate it exactly 
somewhere else (including libraries).  I'm not sure this is possible 
with raw Planet2.  The Ruby community finally dealt with this by saving 
the full library dependency list in a file ("bundle", with version 
numbers) that you save alongside your app.  It works fairly well.


Their experience suggests that accidental backwards incompatible changes 
in libraries happen frequently enough to need some kind of support for.  
Compatibility with the core language was not supported.  Either a 
library's webpage would say "requires ruby core >= 1.8.x", or sometimes 
importing the library would produce an error message telling you the same.


Do these use cases make sense?  (I'd like to hear about library 
developer use cases, but I have no experience there)


Thanks,
Dave
_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] planet2 and versions

[Asumu Takikawa]

On 2012-12-12 14:29:32 -0500, Ryan Culpepper wrote:
> I'm trying to understand how things are supposed to work in planet2
> without version information.

Maybe this was discussed in the other (quite long) thread about Planet
2, but another thing that the lack of versions makes difficult is having
both a development version of a package and a release version installed.

That is, I find it useful to develop a package with a local link (e.g.,
raco pkg install --link foo/). Eventually, I'll put up what I have on
the central server. If I understand how things now work correctly,
Planet 2 requires that I uninstall my local link and then install the
uploaded package (since they have conflicting collections).

If I subsequently work on my development version again, I have to
manually uninstall and re-install the package. Doing this dance
repeatedly is tedious.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] planet2 and versions

[Ryan Culpepper]

On 12/12/2012 03:58 PM, Jay McCarthy wrote:

I agree with Carl.

But I would make an even stronger suggestion, I would suggest that you
completely drop support for old Racket versions and if necessary
release "webapis-lts" and "scriblogify-lts" packages that conflict
with "webapis" and can only work on old versions. The LTS ones
wouldn't be included in the DrDr-tested collection of packages, but
the others would be. Casual users should upgrade and users with
serious version problems should upgrade slowly with only the LTS
versions.


If I understand correctly, you are saying that non-LTS packages should 
ignore the recommendation of the FAQ (6.5, "package authors should not 
make backwards incompatible changes to packages").


That doesn't sound like a good solution.

If I want to support users running versions of Racket that are a couple 
releases old, it doesn't work.


If I want to depend on other packages, then in the absence of a standard 
approach I've got to trust that they have the same notions about 
compatibility and versions-encoded-as-package-names as I do. If I want 
to support Racket back to X.Y, I had better hope that the packages I 
depend on do too. That is, I'd have to figure out how each of them (and 
all of their dependencies) handle compatibility instead of just trusting 
that they all follow the single standard approach.


Finally, as a meta-point, is there any evidence that just throwing away 
versions will work? Any precedents? So far, this seems like a classic 
case of throwing the baby out with the bathwater: versions sometimes 
cause problems... so we won't have them. Now we have the same problems 
but fewer tools for handling them. (See also Eli's response.)


If planet2 is aimed at a problem that is restricted in scope somehow 
that it doesn't need to worry about version issues, I still don't 
understand what that narrower problem is. If I'm supposed to think about 
planet2 as a way of distributing code, I'm still confused about what my 
obligations are when I create a package and what I can rely on from 
other packages.


Ryan


I would also hope that P2's lack of an ability to depend on the core
version would induce better backwards and forwards compatibility from
Racket in the version.

But I'm a bit radical on this front, so I assume that we will have a
robust alternative based on Carl's idea that uses P2 underneath it.

Jay

On Wed, Dec 12, 2012 at 1:13 PM, Carl Eastlund  wrote:

I believe it is by design that Planet 2 does not resolve this kind of issue.
This gives us room to experiment with different solutions without committing
to one up-front, since Planet 1 ran into various limitations of its built-in
policies.

I will propose one possible solution for your "webapis" example.  Distribute
a primary wrapper package called "webapis" and separate specific versions
such as "webapis1", "webapis2", and so forth.  Have the code in "webapis"
determine at compile-time which specific version of webapis is appropriate
for the current Racket version and install that package.  The specific
packages would contain the actual code a client would import.  That way,
installing the "webapis" package on any Racket version would install only
the version of the implementation that works.

I don't know if this is a complete solution, but it seems like a reasonable
starting point.  As we figure out what patterns work, they themselves can be
developed as reusable tools and built into their own packages.  I think this
room for improvement will make Planet 2 a much better long-term model than
Planet 1.  Of course we do eventually want a default system that package
developers can use without too much mucking about with "experimental"
versioning systems.  But I think an initial period of "crowd-sourcing" the
design of that system will do us some good.

Carl Eastlund



On Wed, Dec 12, 2012 at 2:29 PM, Ryan Culpepper  wrote:


I'm trying to understand how things are supposed to work in planet2
without version information.

Let's say I release a package, "webapis". Time passes, and I notice that
Racket gets some cool new features (eg, better SSL support) that the
"webapis" package should use. I write the code, and ...

Do I release the new code under the same package name? If so, then the
package breaks for older versions of Racket, because IIUC planet2 has
nothing corresponding to planet1's 'required-core-version field. And there
doesn't seem to be a way to tell Racket "no, sorry, go back to the older
version of the package". (Rather, there's no way for a client to do so. The
fix would be for the package maintainer to release an "upgrade" that reverts
to the old code.) So it seems like it would be really bad for me to release
the new code under the name "webapis".

In other words, if a package changes its dependencies, that's an
incompatible change for the package, and it needs a new name. Right?

Suppose I release the new code as "webapis2". And suppose there's another
package (let's call it "scr

Re: [racket-dev] planet2 and versions

[Eli Barzilay]

On Dec 12, 2012 3:14 PM, "Carl Eastlund"  wrote:
>
> I will propose one possible solution for your "webapis" example.
Distribute a primary wrapper package called "webapis" and separate specific
versions such as "webapis1", "webapis2", and so forth.  Have the code in
"webapis" determine at compile-time which specific version of webapis is
appropriate for the current Racket version and install that package.  The
specific packages would contain the actual code a client would import.
That way, installing the "webapis" package on any Racket version would
install only the version of the implementation that works.

IMO, the fact that such workarounds are already suggested at this early
stage is what makes this a bad idea.  AFAICT, the only positive point is to
experiment with things to come up with something that works, but why is
that needed?  I still believe that the main principle should be to make it
as boring and as conventional as possible, and pretty much all package
systems have the ability to specify required versions, no need for the
multiple version fanciness.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] planet2 and versions

[Ryan Culpepper]

On 12/12/2012 03:13 PM, Carl Eastlund wrote:

I believe it is by design that Planet 2 does not resolve this kind of
issue.  This gives us room to experiment with different solutions
without committing to one up-front, since Planet 1 ran into various
limitations of its built-in policies.

I will propose one possible solution for your "webapis" example.
Distribute a primary wrapper package called "webapis" and separate
specific versions such as "webapis1", "webapis2", and so forth.  Have
the code in "webapis" determine at compile-time which specific version
of webapis is appropriate for the current Racket version and install
that package.  The specific packages would contain the actual code a
client would import.  That way, installing the "webapis" package on any
Racket version would install only the version of the implementation that
works.


IIUC, a package's dependencies are fixed at package creation time; they 
can't be adjusted at compile time. (Well, now that the dependencies are 
specified via an expression in a #lang setup/infotab file, maybe it's 
possible to adjust them at compile time... or maybe installation time? 
But there's still no access to the Racket version, although there's 
access to other things)


Ryan



I don't know if this is a complete solution, but it seems like a
reasonable starting point.  As we figure out what patterns work, they
themselves can be developed as reusable tools and built into their own
packages.  I think this room for improvement will make Planet 2 a much
better long-term model than Planet 1.  Of course we do eventually want a
default system that package developers can use without too much mucking
about with "experimental" versioning systems.  But I think an initial
period of "crowd-sourcing" the design of that system will do us some good.

Carl Eastlund



On Wed, Dec 12, 2012 at 2:29 PM, Ryan Culpepper mailto:r...@cs.utah.edu>> wrote:

I'm trying to understand how things are supposed to work in planet2
without version information.

Let's say I release a package, "webapis". Time passes, and I notice
that Racket gets some cool new features (eg, better SSL support)
that the "webapis" package should use. I write the code, and ...

Do I release the new code under the same package name? If so, then
the package breaks for older versions of Racket, because IIUC
planet2 has nothing corresponding to planet1's
'required-core-version field. And there doesn't seem to be a way to
tell Racket "no, sorry, go back to the older version of the
package". (Rather, there's no way for a client to do so. The fix
would be for the package maintainer to release an "upgrade" that
reverts to the old code.) So it seems like it would be really bad
for me to release the new code under the name "webapis".

In other words, if a package changes its dependencies, that's an
incompatible change for the package, and it needs a new name. Right?

Suppose I release the new code as "webapis2". And suppose there's
another package (let's call it "scriblogify") that depends on
"webapis". If that code wants to use "webapis2", that's a dependency
change, so it would have to be released as "scriblogify2". There's
no way to express "link me with the most recent compatible version
of webapis*", right?

Ryan
_
  Racket Developers list:
http://lists.racket-lang.org/__dev 




_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] planet2 and versions

[Jay McCarthy]

I agree with Carl.

But I would make an even stronger suggestion, I would suggest that you
completely drop support for old Racket versions and if necessary
release "webapis-lts" and "scriblogify-lts" packages that conflict
with "webapis" and can only work on old versions. The LTS ones
wouldn't be included in the DrDr-tested collection of packages, but
the others would be. Casual users should upgrade and users with
serious version problems should upgrade slowly with only the LTS
versions.

I would also hope that P2's lack of an ability to depend on the core
version would induce better backwards and forwards compatibility from
Racket in the version.

But I'm a bit radical on this front, so I assume that we will have a
robust alternative based on Carl's idea that uses P2 underneath it.

Jay

On Wed, Dec 12, 2012 at 1:13 PM, Carl Eastlund  wrote:
> I believe it is by design that Planet 2 does not resolve this kind of issue.
> This gives us room to experiment with different solutions without committing
> to one up-front, since Planet 1 ran into various limitations of its built-in
> policies.
>
> I will propose one possible solution for your "webapis" example.  Distribute
> a primary wrapper package called "webapis" and separate specific versions
> such as "webapis1", "webapis2", and so forth.  Have the code in "webapis"
> determine at compile-time which specific version of webapis is appropriate
> for the current Racket version and install that package.  The specific
> packages would contain the actual code a client would import.  That way,
> installing the "webapis" package on any Racket version would install only
> the version of the implementation that works.
>
> I don't know if this is a complete solution, but it seems like a reasonable
> starting point.  As we figure out what patterns work, they themselves can be
> developed as reusable tools and built into their own packages.  I think this
> room for improvement will make Planet 2 a much better long-term model than
> Planet 1.  Of course we do eventually want a default system that package
> developers can use without too much mucking about with "experimental"
> versioning systems.  But I think an initial period of "crowd-sourcing" the
> design of that system will do us some good.
>
> Carl Eastlund
>
>
>
> On Wed, Dec 12, 2012 at 2:29 PM, Ryan Culpepper  wrote:
>>
>> I'm trying to understand how things are supposed to work in planet2
>> without version information.
>>
>> Let's say I release a package, "webapis". Time passes, and I notice that
>> Racket gets some cool new features (eg, better SSL support) that the
>> "webapis" package should use. I write the code, and ...
>>
>> Do I release the new code under the same package name? If so, then the
>> package breaks for older versions of Racket, because IIUC planet2 has
>> nothing corresponding to planet1's 'required-core-version field. And there
>> doesn't seem to be a way to tell Racket "no, sorry, go back to the older
>> version of the package". (Rather, there's no way for a client to do so. The
>> fix would be for the package maintainer to release an "upgrade" that reverts
>> to the old code.) So it seems like it would be really bad for me to release
>> the new code under the name "webapis".
>>
>> In other words, if a package changes its dependencies, that's an
>> incompatible change for the package, and it needs a new name. Right?
>>
>> Suppose I release the new code as "webapis2". And suppose there's another
>> package (let's call it "scriblogify") that depends on "webapis". If that
>> code wants to use "webapis2", that's a dependency change, so it would have
>> to be released as "scriblogify2". There's no way to express "link me with
>> the most recent compatible version of webapis*", right?
>>
>> Ryan
>> _
>>  Racket Developers list:
>>  http://lists.racket-lang.org/dev
>>
>
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>



-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] planet2 and versions

[Carl Eastlund]

I believe it is by design that Planet 2 does not resolve this kind of
issue.  This gives us room to experiment with different solutions without
committing to one up-front, since Planet 1 ran into various limitations of
its built-in policies.

I will propose one possible solution for your "webapis" example.
Distribute a primary wrapper package called "webapis" and separate specific
versions such as "webapis1", "webapis2", and so forth.  Have the code in
"webapis" determine at compile-time which specific version of webapis is
appropriate for the current Racket version and install that package.  The
specific packages would contain the actual code a client would import.
That way, installing the "webapis" package on any Racket version would
install only the version of the implementation that works.

I don't know if this is a complete solution, but it seems like a reasonable
starting point.  As we figure out what patterns work, they themselves can
be developed as reusable tools and built into their own packages.  I think
this room for improvement will make Planet 2 a much better long-term model
than Planet 1.  Of course we do eventually want a default system that
package developers can use without too much mucking about with
"experimental" versioning systems.  But I think an initial period of
"crowd-sourcing" the design of that system will do us some good.

Carl Eastlund



On Wed, Dec 12, 2012 at 2:29 PM, Ryan Culpepper  wrote:

> I'm trying to understand how things are supposed to work in planet2
> without version information.
>
> Let's say I release a package, "webapis". Time passes, and I notice that
> Racket gets some cool new features (eg, better SSL support) that the
> "webapis" package should use. I write the code, and ...
>
> Do I release the new code under the same package name? If so, then the
> package breaks for older versions of Racket, because IIUC planet2 has
> nothing corresponding to planet1's 'required-core-version field. And there
> doesn't seem to be a way to tell Racket "no, sorry, go back to the older
> version of the package". (Rather, there's no way for a client to do so. The
> fix would be for the package maintainer to release an "upgrade" that
> reverts to the old code.) So it seems like it would be really bad for me to
> release the new code under the name "webapis".
>
> In other words, if a package changes its dependencies, that's an
> incompatible change for the package, and it needs a new name. Right?
>
> Suppose I release the new code as "webapis2". And suppose there's another
> package (let's call it "scriblogify") that depends on "webapis". If that
> code wants to use "webapis2", that's a dependency change, so it would have
> to be released as "scriblogify2". There's no way to express "link me with
> the most recent compatible version of webapis*", right?
>
> Ryan
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/**dev 
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev