Robby, A package is a vehicle for carrying collections. It is not the only such vehicle. It is the collections, or rather the modules in them, which have code and thus need versions. The modules typically inherit their version from the collection.
Currently there is no way to directly attached arbitrary property information to a collection. When a collection is contained in a subdirectory tree, we take the subdirectory name as the name of the collection (name property). But what of the version number? When a collection is contained in a package, we take the suffix of the package name as the version number of the collection (version property). As packages can hold multiple collections and extensions to collections, such groups can also be given version properties in this manner. (Or is there a more direct method, is there some mechanism for attaching properties within the package management system itself?) You explain here that associated with each collection name and version (or collection of collections and extensions) there is a maturity property with possible value of ring-0, ring-1, or ring-2. This association is currently done via external accounting. Perhaps in the future there will be a more formal method of adding properties to collections, or the package naming convention will be modified to embed the information, or perhaps not. Is it the case that the maturity value (ring-0, ring-1, ring-2) is a strong indicator, but does not decide, which collections are included in the a (version level) main distribution? I.e. that distribution choice and ring-0 assignment are not identical? Asked another way, when I do 'apt-get install racket', or an analogous command, do no further installation commands (fresh out of the box), and then use (require X) in a module, with no quotes around the X, then can I know for certain that X is a module that was found in a collection that comes from a ring-0 package? Also, is it true that for all X modules blessed with the property of being ring 0, X can be reached in this manner, or via #lang? I would imagine the answer to this question is no, that the maturity grades do not exactly determine what is included in the distribution, but rather guide users in the reliability of the packages that in some cases they may or may not chose to install. If so then it would be proper to refer to 'main distribution collections' with the strong implication that the included collections are ring-0 stuff, but probably not all of ring-0 stuff, and gosh, perhaps a ring-1 collection is included for something new but very important. It would be interesting information for me as an application developer who is using racket to know that distributions come with only ring-0 packages, that there are other ring-0 packages that have been contributed which I might go get, and other ring-1 or ring-2 packages out there which I might experiment with. Or is the whole idea that if a collection is blessed as being 'ring-0' for racket version Q that determines it is included in the distribution for racket version Q? yeah, so the answer to these questions will help me tweak the doc mods I've made that refer to the 'main distribution collections'. Thanks! On Saturday, May 2, 2015 at 4:16:56 AM UTC+8, robby wrote: > > That sounds like the right distinction (but where the blessedness of > ring-0 is as documented here: > http://docs.racket-lang.org/pkg/Future_Plans.html). But to avoid > proliferation of names, I think we should either say "a collection > from a ring-0 pkg" or find a shorter way to express that concept that > uses some similar of those words instead of using new words. > > And the ring-0 concept is independent of our current distribution. The > pkg system is designed to make it easy to make alternative > distributions that include different sets of pkgs for use in different > contexts. Really the only stable concept related to "the official > distribution" should be if the pkg is in ring 0 or not. > > Overall, I think we should move away from terminology that suggests a > distinction based on a centralized storehouse of "standard" packages, > as much as we reasonably can. Does this make sense? > > Robby > > On Fri, May 1, 2015 at 8:01 AM, Thomas Lynch > <[email protected] <javascript:>> wrote: > > Robby, I don't know if this is good enough, but I was considering, based > on > > Matt's feedback, to call your ring-0 packages "main distribution > > collections" and those that might be a bit suspect and still attribute > to > > individuals, rather than being blessed as part of the distributions, as > > "contributed collections". I'm suggesting placing emphasis on > 'collection' > > rather than package, as I see a package as a vehicle for distributing > > collections (for the most part). Other vehicles also exist for making > > collections native to the installation. Accordingly one would be able > to > > say things like "if you want the X collection, then go get the Y package > - > > that is the best way to do it. ... The Y package will also give you the > Z > > collection, and the A and B modules that will be added to .." > > > > Don't know, this nomenclatures seems to work for what you are getting > at. > > > > On Thursday, April 30, 2015 at 10:56:58 PM UTC+8, robby wrote: > >> > >> Thomas: thank you for helping to clean all this up! It's quite welcome. > >> > >> One thing to consider: if it is at all possible, I think it would be > >> good if we tried to focus on a distinction between collections from > >> ring-0 packages and those that aren't instead of a distinction between > >> collections from pkgs that come from particular authors. That is, one > >> thing we'd like to do is to make distinctions between pkgs that work > >> well and those that don't instead of distinctions between pkgs that > >> come from centralized place or are distinguished only because of some > >> notion of "privilege", instead of some approximation to "quality". > >> > >> Robby > >> > >> On Thu, Apr 30, 2015 at 9:39 AM, Thomas Lynch > >> <[email protected]> wrote: > >> > > >> > for the rest of this, I think I better study this some more before > >> > typing > >> > too much on the docs. I'll just try to get this into module-basics > for > >> > the > >> > new reader (such as myself). > >> > > >> > Thanks for that understanding of library. > >> > > >> > The term 'standard lib' made me wince when I wrote it, just didn't > know > >> > a > >> > better way to say it. Main distribution collection. Thanks. And > the > >> > collections installed later? Perhaps add-on collections or some > such? > >> > Then > >> > taken together the collections with modules that can be accessed > without > >> > quotes (or via #lang) are ___ collections. > >> > > >> > If for the blank we insert installed collections, then there is > >> > conflation > >> > with install as a process, and as an adjective for a package or other > >> > file > >> > that was used in that process (as described earlier). It is even > >> > difficult > >> > to disambiguate with an explanation. Seems like the term used for > this > >> > concept in other language contexts is library. User stuff, and > library > >> > stuff. hmm main distribution library. Additional libraries. > >> > Access > >> > library stuff with unquoted arg on require, or #lang. But library > has > >> > another meaning already. > >> > > >> > How about 'native collections' and 'local collections'. Native > >> > collections > >> > come in two flavors, main distribution, and contributed. A > collection > >> > is > >> > made native through the process of installing it. If it is installed > >> > via > >> > adding a directory to the catalog then the installed collection can > not > >> > be > >> > deleted as racket will use it directly. If it is installed via a > >> > package, > >> > then the installed package can be deleted. native/local .. other > word > >> > pairs can work here. suggestions? > >> > > >> > So then when talking about native/local or installation, emphasis is > on > >> > collections rather than on modules. The understanding is that the > >> > module > >> > inherits its native/local status by virtue of 'being in the > collection'. > >> > If > >> > it is in a native collection then when using require is accessed > without > >> > quotes. If it is local then it is accessed with quotes. > >> > > >> > ... though there is a nuance with packages where installation might > take > >> > a > >> > scatter shot and put modules in more than one collection. Still only > >> > native > >> > modules will be affected. > >> > > >> > Would this native/local thing be good racket speak? > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups > >> > "Racket Developers" group. > >> > To unsubscribe from this group and stop receiving emails from it, > send > >> > an > >> > email to [email protected]. > >> > To post to this group, send email to [email protected]. > >> > To view this discussion on the web visit > >> > > >> > > https://groups.google.com/d/msgid/racket-dev/9c9689ed-76a6-47ec-99f4-97e366f5f01f%40googlegroups.com. > > > >> > > >> > For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "Racket Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to [email protected] <javascript:>. > > To post to this group, send email to [email protected] > <javascript:>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/racket-dev/2f51a866-5a4b-4c2e-9b63-bd4b8a5c678e%40googlegroups.com. > > > > > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/883cc5d6-a183-4156-98ca-0ed3d66d4f83%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
