p.s. prior post, that is test language asking for verification not an explanation of how it is. .. tone changed during editing, sorry abt that..
On Saturday, May 2, 2015 at 9:11:21 AM UTC+8, Thomas Lynch wrote: > > > 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]> 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]. >> > 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/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/412c29c6-b023-4676-8143-f6e0a954b1bb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
