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
