Re: [racket-dev] planet2 and versions
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
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
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
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
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
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
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
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
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
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
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
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
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