FWIW, I have to support Ethan here. (At least a little bit). I really how user installed packages (and collections) in Racket feel like first class citizens. Its very nice, both that its rewarding when I make a new package, but also in terms of searching for documentation and whatnot.
However, there is something to be said about having them show up as results on the _official docs_ on our webpage. Anyone can upload a package to pkgs.racket-lang.org and, provided that it compiles, we'll display the content on our webpage as if it was a first class thing. While we have a sandbox to prevent certain classes of technical malicious attacks we don't really have much in place (other than the community) for social engineering based attacks. For example, I could make a package that looks normal, acts normal, and most of the docs are normal, but in the docs it links to some malicious page, or has misleading content. Well, now we just not only gave this package a platform, but we gave it a platform that looks like we 100% endorse it, because its mixed seamlessly in with the API that ships with the core distribution. I don't think that the solution is to make core packages first class, and community ones second class. That looses the spirit of what we're going for here. But maybe we could have in our documentation a way for users to select what packages they want to show up in search results. That way all packages are equal here, and a person who wants to, say, only use core packages, can get that. An alternative approach which probably takes less effort is to just have two documentation pages. One for core packages, and one for community packages. Obviously we should still make 3rd party packages feel like first class build in stuff, but if we just host them at a different URL, that might be enough to keep things clear. just some thoughts anyway. ~Leif Andersen On Sun, Jan 29, 2017 at 3:48 PM, Ethan Estrada <ethan.estr...@gmail.com> wrote: > Curse my sausage fingers! That last send was unintentional. I've deleted > it from the online Google Groups forum for the sake of future subscribers. > > I can understand wanting to minimize the distinction and in some ways make > all core language, standard libraries, and community libraries equal. > > For me the issue is software maintenance. If I'm building something that > needs functionality from an external library, I'm more likely to choose a > library from the standard install if one exists. I can be reasonably > certain it will be supported for a long time into the future, and if it > ever ceases to be supported it will likely be gracefully deprecated over > the course of a few releases. Neither of those points are guaranteed, but I > think they are reasonable assumptions to make. > > Also, to some extent there already is a distinction in the documentation. > There is the section "Racket Language and Core Libraries", and then there > is everything else. However, the libraries from the 'base' package and > other shipped packages are sprinkled into the "everything else" docs and > not all the shipped packages are listed under "Racket Language and Core > Libraries". So it makes things murky. > > A possible compromise may be to have the top level page of http:// > docs.racket-lang.org/ remain the same, but have a small link/page under > http://docs.racket-lang.org/reference/ page that lists the links to all > the packages/libraries/collections that are shipped by default with Racket. > The pages that the links point to would all still live where they always > have and still be listed at the top level http://docs.racket-lang.org/ > the same way they already are. That way there is some centralized place to > figure out what ships with racket without mucking around the filesystem > after install, or checking on each link on http://docs.racket-lang.org/ > to see if the package it requires from is 'base' or something else core to > the install. > > To Stephen, thanks for sharing the articles from Eric Raymond. It made me > think maybe I'm not just a crazy guy on the street corner wearing a burlap > sack and a tin foil hat declaring the end of the world. Or, at the very > least, I'm not alone on the street corner :) . > > -- > Ethan Estrada > > On Jan 29, 2017 06:45, "Matthew Flatt" <mfl...@cs.utah.edu> wrote: > > At Sat, 28 Jan 2017 22:51:43 -0800 (PST), Ethan Estrada wrote: > > My only real beef with the Racket docs are the layout of packages; > > there is no clear distinction between docs for standard library items > > and docs for community provided libs. > > That's intentional. I'd say that the absence of a line that > distinguishes "Racket" from "not Racket" at the package level is an > extrapolation of our goal to avoid a line between the "language" and > "library" at the level of a module. > > There are certainly some drawbacks to allowing any old module to add > new constructs to the programming language, but we think the benefits > outweigh the drawbacks. Similarly, there are some drawbacks to allowing > any old package to have the same status as the base system, but I > believe in the benefits. > > In both cases, it's important that programmers have control over what > is used and what isn't used. The module system enforces boundaries so > that a module added to a program can't have an arbitrary effect on > other modules in the program. Similarly, the package system is intended > to give the programmer control over what packages are installed and how > they are installed. > > I'm not objecting to improvement here --- just trying to clarify why > the current organization is like that. > > Also, I'd concede that we have a notion of "main distribution", which > identifies a set of packages that are included in the Racket installers > at racket-lang.org. That's a useful concept, but I see it as a > compromise, and I'm reluctant to reflect that distinction in the > documentation. > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
