Re: [racket-dev] Packaging
I don't feel strongly about this and you seem to, so supposing we support any conflicting installations, it makes sense for Planet 2.0 to have both major and minor versions. Jay 2011/2/19 Robby Findler ro...@eecs.northwestern.edu: On Sat, Feb 19, 2011 at 10:18 AM, Robby Findler ro...@eecs.northwestern.edu wrote: It looks to me like you there is relevant, important metadata that you're making someone fold into an implicit place instead of an explicit one. Will you have a convention for these? What if I decide to call mine libgtk2.0 and someone else calls theirs somepackage-2? That doesn't seem good fo [ Sorry; got distracted here and forgot to come back. ] That doesn't seem good for users who are trying to find packages. Especially if I were to call mine 2-somepackage (you may think this far fetched, but if you look you should find an example of this in our current collection tree) Robby -- 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
Good point Jay 2011/2/19 Eli Barzilay e...@barzilay.org: 5 hours ago, Jay McCarthy wrote: 2011/2/18 Jos Koot jos.k...@telefonica.net: For a simple windows 7 user as I it is rather difficult to use command line instructions. I plead for an easy to use gui for making contributions. I think this is orthogonal to the project, but I do mention how important it is to have an easy way of getting packages post-installation. I was imagining that this would be a separate GUI tool that was auto-launched on Windows installation and suggested on first launch of DrRacket. General reminder: when you're at the first launch step, you're already beyond the point of adding installation wide content. You're some student in some class that is annoyed at their sysadmins not installing something, and annoyed at the constant popups since they're working on public machines that are getting wiped on every logout. Or you're a sysadmin that gets annoyed at the fact that the need to interact with the installer. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
Do you mean to inherit Planet's current version number semantics? Uh. Assigning a fixed structure and semantics to version numbers was one of the worst things Planet did. Dracula is up to 8:18, and goodness knows what that means. It does not mean there have been 8 significantly different versions of Dracula, such that I gave the release bigger fanfare than usual. It means there were 8 times when some potential incompatibility between releases occurred to me between the time of package creation and the time of upload. That should not be how version numbers are determined. It is not at all clear to me that version numbers should serve as an automatic metric of compatibility or upgrade-ability; let's either come up with a metric that is more to the point, or stop trying so hard to enforce things like no compatibility regressions that are often hard to detect in the first place. Carl Eastlund On Tue, Feb 22, 2011 at 3:37 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I don't feel strongly about this and you seem to, so supposing we support any conflicting installations, it makes sense for Planet 2.0 to have both major and minor versions. Jay 2011/2/19 Robby Findler ro...@eecs.northwestern.edu: On Sat, Feb 19, 2011 at 10:18 AM, Robby Findler ro...@eecs.northwestern.edu wrote: It looks to me like you there is relevant, important metadata that you're making someone fold into an implicit place instead of an explicit one. Will you have a convention for these? What if I decide to call mine libgtk2.0 and someone else calls theirs somepackage-2? That doesn't seem good fo [ Sorry; got distracted here and forgot to come back. ] That doesn't seem good for users who are trying to find packages. Especially if I were to call mine 2-somepackage (you may think this far fetched, but if you look you should find an example of this in our current collection tree) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
Carl: your message is unclear to me. Are you saying that attempting to solve the problem of matching up require requests with available versions of software packages is hopeless and we shouldn't attempt it, or are you saying that we should use something that is not (literally) called version number or are you saying something else? Robby On Tue, Feb 22, 2011 at 3:01 PM, Carl Eastlund c...@ccs.neu.edu wrote: Do you mean to inherit Planet's current version number semantics? Uh. Assigning a fixed structure and semantics to version numbers was one of the worst things Planet did. Dracula is up to 8:18, and goodness knows what that means. It does not mean there have been 8 significantly different versions of Dracula, such that I gave the release bigger fanfare than usual. It means there were 8 times when some potential incompatibility between releases occurred to me between the time of package creation and the time of upload. That should not be how version numbers are determined. It is not at all clear to me that version numbers should serve as an automatic metric of compatibility or upgrade-ability; let's either come up with a metric that is more to the point, or stop trying so hard to enforce things like no compatibility regressions that are often hard to detect in the first place. Carl Eastlund On Tue, Feb 22, 2011 at 3:37 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I don't feel strongly about this and you seem to, so supposing we support any conflicting installations, it makes sense for Planet 2.0 to have both major and minor versions. Jay 2011/2/19 Robby Findler ro...@eecs.northwestern.edu: On Sat, Feb 19, 2011 at 10:18 AM, Robby Findler ro...@eecs.northwestern.edu wrote: It looks to me like you there is relevant, important metadata that you're making someone fold into an implicit place instead of an explicit one. Will you have a convention for these? What if I decide to call mine libgtk2.0 and someone else calls theirs somepackage-2? That doesn't seem good fo [ Sorry; got distracted here and forgot to come back. ] That doesn't seem good for users who are trying to find packages. Especially if I were to call mine 2-somepackage (you may think this far fetched, but if you look you should find an example of this in our current collection tree) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
I am saying we should use something that is not called version number. On the IRC list I have suggested -- without too much thought behind it yet -- that we construct an upgrade graph; package maintainers can specify which package can be thought of as an automatic improvement on another, and some appropriate part of the Planet mechanism can therefore follow a chain of these links to find the best available candidate for a require. That allows package names, version numbers, and other string-based user-readable package-identifying features to be uninterpreted, and written however the maintainer wants. Carl Eastlund On Tue, Feb 22, 2011 at 4:06 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Carl: your message is unclear to me. Are you saying that attempting to solve the problem of matching up require requests with available versions of software packages is hopeless and we shouldn't attempt it, or are you saying that we should use something that is not (literally) called version number or are you saying something else? Robby On Tue, Feb 22, 2011 at 3:01 PM, Carl Eastlund c...@ccs.neu.edu wrote: Do you mean to inherit Planet's current version number semantics? Uh. Assigning a fixed structure and semantics to version numbers was one of the worst things Planet did. Dracula is up to 8:18, and goodness knows what that means. It does not mean there have been 8 significantly different versions of Dracula, such that I gave the release bigger fanfare than usual. It means there were 8 times when some potential incompatibility between releases occurred to me between the time of package creation and the time of upload. That should not be how version numbers are determined. It is not at all clear to me that version numbers should serve as an automatic metric of compatibility or upgrade-ability; let's either come up with a metric that is more to the point, or stop trying so hard to enforce things like no compatibility regressions that are often hard to detect in the first place. Carl Eastlund On Tue, Feb 22, 2011 at 3:37 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I don't feel strongly about this and you seem to, so supposing we support any conflicting installations, it makes sense for Planet 2.0 to have both major and minor versions. Jay 2011/2/19 Robby Findler ro...@eecs.northwestern.edu: On Sat, Feb 19, 2011 at 10:18 AM, Robby Findler ro...@eecs.northwestern.edu wrote: It looks to me like you there is relevant, important metadata that you're making someone fold into an implicit place instead of an explicit one. Will you have a convention for these? What if I decide to call mine libgtk2.0 and someone else calls theirs somepackage-2? That doesn't seem good fo [ Sorry; got distracted here and forgot to come back. ] That doesn't seem good for users who are trying to find packages. Especially if I were to call mine 2-somepackage (you may think this far fetched, but if you look you should find an example of this in our current collection tree) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
Thanks for clarifying. And I'm sure you must know about it and I'm a bit afraid to even bring it up, but you might want to use planet's external version feature. Robby On Tue, Feb 22, 2011 at 3:32 PM, Carl Eastlund c...@ccs.neu.edu wrote: I am saying we should use something that is not called version number. On the IRC list I have suggested -- without too much thought behind it yet -- that we construct an upgrade graph; package maintainers can specify which package can be thought of as an automatic improvement on another, and some appropriate part of the Planet mechanism can therefore follow a chain of these links to find the best available candidate for a require. That allows package names, version numbers, and other string-based user-readable package-identifying features to be uninterpreted, and written however the maintainer wants. Carl Eastlund On Tue, Feb 22, 2011 at 4:06 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Carl: your message is unclear to me. Are you saying that attempting to solve the problem of matching up require requests with available versions of software packages is hopeless and we shouldn't attempt it, or are you saying that we should use something that is not (literally) called version number or are you saying something else? Robby On Tue, Feb 22, 2011 at 3:01 PM, Carl Eastlund c...@ccs.neu.edu wrote: Do you mean to inherit Planet's current version number semantics? Uh. Assigning a fixed structure and semantics to version numbers was one of the worst things Planet did. Dracula is up to 8:18, and goodness knows what that means. It does not mean there have been 8 significantly different versions of Dracula, such that I gave the release bigger fanfare than usual. It means there were 8 times when some potential incompatibility between releases occurred to me between the time of package creation and the time of upload. That should not be how version numbers are determined. It is not at all clear to me that version numbers should serve as an automatic metric of compatibility or upgrade-ability; let's either come up with a metric that is more to the point, or stop trying so hard to enforce things like no compatibility regressions that are often hard to detect in the first place. Carl Eastlund On Tue, Feb 22, 2011 at 3:37 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I don't feel strongly about this and you seem to, so supposing we support any conflicting installations, it makes sense for Planet 2.0 to have both major and minor versions. Jay 2011/2/19 Robby Findler ro...@eecs.northwestern.edu: On Sat, Feb 19, 2011 at 10:18 AM, Robby Findler ro...@eecs.northwestern.edu wrote: It looks to me like you there is relevant, important metadata that you're making someone fold into an implicit place instead of an explicit one. Will you have a convention for these? What if I decide to call mine libgtk2.0 and someone else calls theirs somepackage-2? That doesn't seem good fo [ Sorry; got distracted here and forgot to come back. ] That doesn't seem good for users who are trying to find packages. Especially if I were to call mine 2-somepackage (you may think this far fetched, but if you look you should find an example of this in our current collection tree) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
I am aware of the external versions, but since I can't put them in a require spec to identify the package I want, they aren't terribly useful as an identifying feature of a package. Carl Eastlund On Tue, Feb 22, 2011 at 4:34 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Thanks for clarifying. And I'm sure you must know about it and I'm a bit afraid to even bring it up, but you might want to use planet's external version feature. Robby On Tue, Feb 22, 2011 at 3:32 PM, Carl Eastlund c...@ccs.neu.edu wrote: I am saying we should use something that is not called version number. On the IRC list I have suggested -- without too much thought behind it yet -- that we construct an upgrade graph; package maintainers can specify which package can be thought of as an automatic improvement on another, and some appropriate part of the Planet mechanism can therefore follow a chain of these links to find the best available candidate for a require. That allows package names, version numbers, and other string-based user-readable package-identifying features to be uninterpreted, and written however the maintainer wants. Carl Eastlund On Tue, Feb 22, 2011 at 4:06 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Carl: your message is unclear to me. Are you saying that attempting to solve the problem of matching up require requests with available versions of software packages is hopeless and we shouldn't attempt it, or are you saying that we should use something that is not (literally) called version number or are you saying something else? Robby On Tue, Feb 22, 2011 at 3:01 PM, Carl Eastlund c...@ccs.neu.edu wrote: Do you mean to inherit Planet's current version number semantics? Uh. Assigning a fixed structure and semantics to version numbers was one of the worst things Planet did. Dracula is up to 8:18, and goodness knows what that means. It does not mean there have been 8 significantly different versions of Dracula, such that I gave the release bigger fanfare than usual. It means there were 8 times when some potential incompatibility between releases occurred to me between the time of package creation and the time of upload. That should not be how version numbers are determined. It is not at all clear to me that version numbers should serve as an automatic metric of compatibility or upgrade-ability; let's either come up with a metric that is more to the point, or stop trying so hard to enforce things like no compatibility regressions that are often hard to detect in the first place. Carl Eastlund On Tue, Feb 22, 2011 at 3:37 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I don't feel strongly about this and you seem to, so supposing we support any conflicting installations, it makes sense for Planet 2.0 to have both major and minor versions. Jay 2011/2/19 Robby Findler ro...@eecs.northwestern.edu: On Sat, Feb 19, 2011 at 10:18 AM, Robby Findler ro...@eecs.northwestern.edu wrote: It looks to me like you there is relevant, important metadata that you're making someone fold into an implicit place instead of an explicit one. Will you have a convention for these? What if I decide to call mine libgtk2.0 and someone else calls theirs somepackage-2? That doesn't seem good fo [ Sorry; got distracted here and forgot to come back. ] That doesn't seem good for users who are trying to find packages. Especially if I were to call mine 2-somepackage (you may think this far fetched, but if you look you should find an example of this in our current collection tree) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
I've batch my responses to yesterday's questions together. As a general note, I'd like to have my document be an accurate reflection of what I should do when I start coding, so if you think I should update it to clarify the answers to these questions, please let me know. I'm blinded a bit by my intentions when I read it. 2011/2/18 Robby Findler ro...@eecs.northwestern.edu: Minor comment: why encourage names like libgtk and libgtk2 instead of a major and minor version number (ala PLaneT)? Don't we want those two libraries to be associated somehow (at least loosely)? I think having libgtk and libgtk2 alleviates a confusion with the most recent version policy. For example, I write my package when there is only libgtk and I don't specify which version I want, because any will do. Later libgtk gets upgraded and its second major version is not fully backwards compatible. I don't think it is plausible for the reader of my package metadata to know that I didn't know about the new version and SHOULD have written a major version 1 requirement, but didn't. By having a strict separation between major versions, I think it is kinder to less specific package metadata. (If you look around PLaneT, very few packages actually specify their dependencies with much detail.) As a slight social engineering, this policy also makes it easier to provide alternatives to dead packages, because upgrading to an alternative vendor is no harder than upgrading to the official version. Also, it may discourage new major versions and therefore encourage more compatibility. Also, it also isn't clear which of the complaints with PLaneT you're actually dealing with. I don't see anything about security for example or the discovery issue. By moving package dependencies outside of modules and allowing a system-wide installation, I attack the second-class-nes of PLaneT. By a different default policy, I attack the upgrade path. By having a more exposed directory structure and looser package hosting constraints, I attack the improvement problem. On the social site by having reputation, reviews, and tags, I hope to solve the discovery problem. By allowing any URL (without a custom server) as a package source, I hope to solve the centralization problem. By making the packaging system more capable, I hope to decrease the size of the core. Once that happens, those packages can be independently upgraded. On the security defaults, by using URLs, we can use HTTPS to get slightly better security. I mention having checksums on package files to ensure the right file was got. By allowing private repositories, you can ensure that you control your security destiny. I solve the unintended installation problem by making package installation separate from the runtime, where we could provide an apt-get style of these are the other packages that will be installed. I solve the module privacy with the linking directories. I have no solution for expensive installations (indeed in my final open problems I mention how we would store compiled code at the server.) The other part of installation---documentation---could be solved the same way we do now (explicit option to not build) and have better searching on the package site. My solution for untrustworth packages is a rather weak black balling. I think sandboxing compilation is outside the short-term scope of this project. And one fairly abstract worry: can I end up in a situation where I had a working system with dependencies between packages being obvious but install a new package and fall out of the obvious realm in some potentially confusing way? I think this is the most confusing situation: - Install package A that requires B - Develop a packageless program that uses B - Upgrade to a new provider of B's features... B2 Your packageless program uses B2, but A still uses B, even though you may think of them as the same package. I think the alternative behavior, that A starts using a different provider, is worse though. 2011/2/18 Jos Koot jos.k...@telefonica.net: I read your contribution with great interest. One problem that is not addressed, as far as I have seen, is that any idiot, like me, can install his/her contributions (modules/collections/packages or whatever) For a simple windows 7 user as I it is rather difficult to use command line instructions. I plead for an easy to use gui for making contributions. I think this is orthogonal to the project, but I do mention how important it is to have an easy way of getting packages post-installation. I was imagining that this would be a separate GUI tool that was auto-launched on Windows installation and suggested on first launch of DrRacket. I also plead for an option to delete contributions that have never been dowloaded by anyone else than the contributor (would that be possible?) I once contributed a module wrongly. I am sure it has never been dowloaded, but I have no option to correct my silly mistake. All I could do is to upload
Re: [racket-dev] Packaging
On Sat, Feb 19, 2011 at 9:39 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I've batch my responses to yesterday's questions together. As a general note, I'd like to have my document be an accurate reflection of what I should do when I start coding, so if you think I should update it to clarify the answers to these questions, please let me know. I'm blinded a bit by my intentions when I read it. 2011/2/18 Robby Findler ro...@eecs.northwestern.edu: Minor comment: why encourage names like libgtk and libgtk2 instead of a major and minor version number (ala PLaneT)? Don't we want those two libraries to be associated somehow (at least loosely)? I think having libgtk and libgtk2 alleviates a confusion with the most recent version policy. For example, I write my package when there is only libgtk and I don't specify which version I want, because any will do. Later libgtk gets upgraded and its second major version is not fully backwards compatible. I don't think it is plausible for the reader of my package metadata to know that I didn't know about the new version and SHOULD have written a major version 1 requirement, but didn't. By having a strict separation between major versions, I think it is kinder to less specific package metadata. (If you look around PLaneT, very few packages actually specify their dependencies with much detail.) As a slight social engineering, this policy also makes it easier to provide alternatives to dead packages, because upgrading to an alternative vendor is no harder than upgrading to the official version. It looks to me like you there is relevant, important metadata that you're making someone fold into an implicit place instead of an explicit one. Will you have a convention for these? What if I decide to call mine libgtk2.0 and someone else calls theirs somepackage-2? That doesn't seem good fo Also, it may discourage new major versions and therefore encourage more compatibility. This doesn't seem to follow. :) Also, it also isn't clear which of the complaints with PLaneT you're actually dealing with. I don't see anything about security for example or the discovery issue. By moving package dependencies outside of modules and allowing a system-wide installation, I attack the second-class-nes of PLaneT. By a different default policy, I attack the upgrade path. By having a more exposed directory structure and looser package hosting constraints, I attack the improvement problem. On the social site by having reputation, reviews, and tags, I hope to solve the discovery problem. By allowing any URL (without a custom server) as a package source, I hope to solve the centralization problem. By making the packaging system more capable, I hope to decrease the size of the core. Once that happens, those packages can be independently upgraded. On the security defaults, by using URLs, we can use HTTPS to get slightly better security. I mention having checksums on package files to ensure the right file was got. By allowing private repositories, you can ensure that you control your security destiny. I solve the unintended installation problem by making package installation separate from the runtime, where we could provide an apt-get style of these are the other packages that will be installed. I solve the module privacy with the linking directories. I have no solution for expensive installations (indeed in my final open problems I mention how we would store compiled code at the server.) The other part of installation---documentation---could be solved the same way we do now (explicit option to not build) and have better searching on the package site. My solution for untrustworth packages is a rather weak black balling. I think sandboxing compilation is outside the short-term scope of this project. These seem reasonable, but I did not get a clear connection when reading your essay. My comment is probably a presentation one, then. In general, the essay seems long on problem descriptions and short on solution descriptions, relying on the reader to be familiar with low-level details of Racket and having to be able to synthesize from them how things will interact. I suspect that a high-level description of the solution you're imagining (and possibly some more specific uses cases) will make your essay more readable (as you may have noticed, most of the replies don't actually say anything about your proposed solution in any detail; probably because we can't understand it). And one fairly abstract worry: can I end up in a situation where I had a working system with dependencies between packages being obvious but install a new package and fall out of the obvious realm in some potentially confusing way? I think this is the most confusing situation: - Install package A that requires B - Develop a packageless program that uses B - Upgrade to a new provider of B's features... B2 Your packageless program uses B2, but A still uses B,
Re: [racket-dev] Packaging
On Sat, Feb 19, 2011 at 10:18 AM, Robby Findler ro...@eecs.northwestern.edu wrote: It looks to me like you there is relevant, important metadata that you're making someone fold into an implicit place instead of an explicit one. Will you have a convention for these? What if I decide to call mine libgtk2.0 and someone else calls theirs somepackage-2? That doesn't seem good fo [ Sorry; got distracted here and forgot to come back. ] That doesn't seem good for users who are trying to find packages. Especially if I were to call mine 2-somepackage (you may think this far fetched, but if you look you should find an example of this in our current collection tree) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
I think that the versioning problem is an important and hard one, and the obvious first place to turn this infrastructure work into a research result. Racket gives you a significant opportunity that others would not have (for a certain class of solutions, at least). Even better, we have significant experience with one end of the spectrum and, of course, there are lots of other attempts out there that we should also be able to extract experience from if we dig into linux distros and their communities, etc. Robby On Sat, Feb 19, 2011 at 3:53 PM, Jay McCarthy jay.mccar...@gmail.com wrote: Eli, you have a lot of very good points that I will try to respond to individually later. I think the highest bit issue you bring up is conflicts. (Multiple versions are a special case of conflicts between packages.) I see three options 1. Totally disallow conflicts 2. Make conflicting installations irregular 3. Make conflicting installations normal I think (1) is epitomized by a single location that packages get copied into as they are installed. I think (2) is epitomized by something like (1) with a secret place on the side for conflicts to be stored. I think my proposal is (3). I think the way I proposed to deal with conflicts dovetails nicely into dealing with module privacy. I like the way that keeping things in separate directories always makes it easy to deal with version control. I also like the decoupling of package names and the modules they provide. I'd like to know where our community stands on this issue, because if most are happy with (1), then I think the packaging system could be much simpler. I personally think (2) is more complicated than (3). 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Packaging
You may recall from the meeting over the summer that I promised a packaging Christmas present to Racket. I'm over a month late, but here it is: http://faculty.cs.byu.edu/~jay/tmp/pkgs/spec.html I lay out some goals for the new packaging system and make a concrete proposal. Please share your feedback so I can direct my efforts better. 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
Minor comment: why encourage names like libgtk and libgtk2 instead of a major and minor version number (ala PLaneT)? Don't we want those two libraries to be associated somehow (at least loosely)? Also, it also isn't clear which of the complaints with PLaneT you're actually dealing with. I don't see anything about security for example or the discovery issue. And one fairly abstract worry: can I end up in a situation where I had a working system with dependencies between packages being obvious but install a new package and fall out of the obvious realm in some potentially confusing way? Robby On Friday, February 18, 2011, Jay McCarthy wrote: You may recall from the meeting over the summer that I promised a packaging Christmas present to Racket. I'm over a month late, but here it is: http://faculty.cs.byu.edu/~jay/tmp/pkgs/spec.html I lay out some goals for the new packaging system and make a concrete proposal. Please share your feedback so I can direct my efforts better. Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
I read your contribution with great interest. One problem that is not addressed, as far as I have seen, is that any idiot, like me, can install his/her contributions (modules/collections/packages or whatever) For a simple windows 7 user as I it is rather difficult to use command line instructions. I plead for an easy to use gui for making contributions. I also plead for an option to delete contributions that have never been dowloaded by anyone else than the contributor (would that be possible?) I once contributed a module wrongly. I am sure it has never been dowloaded, but I have no option to correct my silly mistake. All I could do is to upload an empty version, but the former version is still there. As for security, would it be possible to sandbox a download with some restrictions/options of permissions (opening files, creating new files, deleting files, renaming files, calling foreign applications, enter internet or email, and so on)??? Jos -Original Message- From: dev-boun...@racket-lang.org [mailto:dev-boun...@racket-lang.org] On Behalf Of Jay McCarthy Sent: 18 February 2011 22:21 To: dev Subject: [racket-dev] Packaging You may recall from the meeting over the summer that I promised a packaging Christmas present to Racket. I'm over a month late, but here it is: http://faculty.cs.byu.edu/~jay/tmp/pkgs/spec.html I lay out some goals for the new packaging system and make a concrete proposal. Please share your feedback so I can direct my efforts better. 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
Jay - 1. Thanks for having this out - this is a great start and a very important problem to solve 2. Is it correct that *heap* maps to the account name in planet? Such as jaymccarthy, schematics, or bzlib? There is always tension between the naming by capability or author in package systems. Do we have a preference one way or another? 3. For all the modules that are currently in core, it might make sense to simply lump them under a *core* heap to simplify the reorganization, but it's clear that not all packages are strictly required, so it would eventually be great to separate them out: 1. absolute core (scheme racket language, no GUI) 2. GUI 3. other languages 4. etc 4. Agreed that the installation/compilation takes way too long. Would like the ability to turn off doc installation - I believe docs needs to be online, and easily updated, i.e. wiki format 5. Another thing to improve the time of installation is to have pre-compiled binaries. If this is a possibility, then perhaps binary-only package should also be considered. That might not be the open source ideal, but can increase more adoption 6. Planet packages also have problems with dependency breakage when the dependency is a development link. So that will need to be addressed 7. It's hard to understand the Glue section - are you suggesting having the URL embedded into the require spec? I hope I am reading it incorrectly, as such hardcoding should be avoided. 8. The Linux repo (such as apt or yum) should be the preferred approach here - having a repo definition that defines where to search for packages. Such approach allows for having planet mirrors and private repos The above are what I can think of for now. Cheers. yc On Fri, Feb 18, 2011 at 1:21 PM, Jay McCarthy jay.mccar...@gmail.comwrote: You may recall from the meeting over the summer that I promised a packaging Christmas present to Racket. I'm over a month late, but here it is: http://faculty.cs.byu.edu/~jay/tmp/pkgs/spec.html I lay out some goals for the new packaging system and make a concrete proposal. Please share your feedback so I can direct my efforts better. Jay _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
One more comment: one of PLaneT's design goals what that if you have a working system and you install a new planet package, then you didn't break any of the working parts from before. The new system doesn't seem to have that as a design goal anymore (I noticed automatic upgrades and freezing being an explicit operation but there may be other places). Do you have a rationale for deviating from this seemingly nice property? Robby On Fri, Feb 18, 2011 at 3:21 PM, Jay McCarthy jay.mccar...@gmail.com wrote: You may recall from the meeting over the summer that I promised a packaging Christmas present to Racket. I'm over a month late, but here it is: http://faculty.cs.byu.edu/~jay/tmp/pkgs/spec.html I lay out some goals for the new packaging system and make a concrete proposal. Please share your feedback so I can direct my efforts better. 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
On Fri, Feb 18, 2011 at 8:17 PM, Robby Findler ro...@eecs.northwestern.edu wrote: One more comment: one of PLaneT's design goals what that if you have a working system and you install a new planet package, then you didn't break any of the working parts from before. The new system doesn't seem to have that as a design goal anymore (I noticed automatic upgrades and freezing being an explicit operation but there may be other places). Do you have a rationale for deviating from this seemingly nice property? I think (from my experience working on this problem in the Fortress context) that this property isn't as nice as it seems to start with. It has a few important problems: 1. It can't possible be true in general, since two packages or (especially) two versions of the same package can contend for the same system resource (a file, a database, a network port, a parameter, a bit of Racket global state, etc). 2. It's in conflict with two other important goals -- upgrading packages (to remove bugs, add features, etc) and reducing resource usage (disk, memory, etc). 3. Often, sharing state in a package/library is very important. For example, generative structs have to be generated only once to be properly shared. With the planet policy, it's all to easy to install two packages, both of which require (planet foo/bar), get different instantiations of foo/bar, and have the two packages be subtly incompatible (it's even worse when the incompatibility is in some shared resource other than generative structs, like shared files). We've had this problem with planet libraries, I believe. I believe the right solution is to allow individual library authors to specify that they want the planet policy, or some other policy, to be applied to particular dependencies, without making it the default. Robby On Fri, Feb 18, 2011 at 3:21 PM, Jay McCarthy jay.mccar...@gmail.com wrote: You may recall from the meeting over the summer that I promised a packaging Christmas present to Racket. I'm over a month late, but here it is: http://faculty.cs.byu.edu/~jay/tmp/pkgs/spec.html I lay out some goals for the new packaging system and make a concrete proposal. Please share your feedback so I can direct my efforts better. 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
