Re: [racket-dev] planet2 and versions

2012-12-13 Thread Jay McCarthy
On Wed, Dec 12, 2012 at 4:01 PM, Ryan Culpepper r...@cs.utah.edu 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 c...@ccs.neu.edu 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 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 

Re: [racket-dev] planet2 and versions

2012-12-13 Thread Jay McCarthy
On Wed, Dec 12, 2012 at 8:55 PM, Asumu Takikawa as...@ccs.neu.edu 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 j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

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


Re: [racket-dev] planet2 and versions

2012-12-13 Thread Jay McCarthy
On Wed, Dec 12, 2012 at 11:48 PM, David Vanderson
david.vander...@gmail.com 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 j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

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


Re: [racket-dev] planet2 and versions

2012-12-13 Thread 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

2012-12-13 Thread 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


[racket-dev] planet2 and versions

2012-12-12 Thread Ryan Culpepper
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


Re: [racket-dev] planet2 and versions

2012-12-12 Thread 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 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 http://lists.racket-lang.org/dev


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


Re: [racket-dev] planet2 and versions

2012-12-12 Thread 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 c...@ccs.neu.edu 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 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




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

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


Re: [racket-dev] planet2 and versions

2012-12-12 Thread 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 r...@cs.utah.edu
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 http://lists.racket-lang.org/dev




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


Re: [racket-dev] planet2 and versions

2012-12-12 Thread Eli Barzilay
On Dec 12, 2012 3:14 PM, Carl Eastlund c...@ccs.neu.edu 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

2012-12-12 Thread 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 c...@ccs.neu.edu 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 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 

Re: [racket-dev] planet2 and versions

2012-12-12 Thread 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

2012-12-12 Thread 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