Re: [racket-dev] Splitting the Racket repository

I believe I've fixed everything shown on for which I'm responsible: aws: Commits merged to master and pushed. http: Fixed a buggy test mishandling 301/302 redirects. sha: Nothing needed to be fixed. I'll keep an eye on DrDr; Sam said he'd a

Re: [racket-dev] Splitting the Racket repository

At Sat, 29 Nov 2014 22:00:44 -0500, Eli Barzilay wrote: > On Sat, Nov 29, 2014 at 8:30 PM, Sam Tobin-Hochstadt > wrote: > > On Sat, Nov 29, 2014 at 8:16 PM, Eli Barzilay wrote: > >> On Sat, Nov 29, 2014 at 7:14 PM, Sam Tobin-Hochstadt > >> wrote: > >>> To clone individual repositories, use the n

Re: [racket-dev] Splitting the Racket repository

Sam gave me a heads-up on IRC. > Also, DrDr now builds several packages that it didn't before: the > s3-sync, sha, http, and aws packages. Currently, these packages have > some test failures, but we hope to fix that soon. I'm responsible for aws, http, and sha. I'm working on this. I'm close to

Re: [racket-dev] Splitting the Racket repository

On Sat, Nov 29, 2014 at 7:14 PM, Sam Tobin-Hochstadt wrote: > > # Changes for git users > > If you build Racket from source from Git, that build now contains > fewer packages. There is not yet an single-step way to get all of the > split pkgs as git repositories; we plan to write a script for this

Re: [racket-dev] new package system collections and conflicts

On Sun, Nov 30, 2014 at 12:40 PM, Neil Van Dyke wrote: > > Jay McCarthy wrote on 11/30/2014 12:30 PM: >> >> On Sunday, November 30, 2014, Neil Van Dyke > > wrote: >> >> >> Jay McCarthy wrote on 11/30/2014 12:13 PM: >> >> The documentation cited is making cl

Re: [racket-dev] new package system collections and conflicts

Just to be clear. I don't think that "tic-tac-toe" and "data/matrix" are the important thing in this example. The important thing is that the package name and the module don't share a prefix. Another good example would be something like "graphs" and "data/fib-heap" or something where it may to be e

Re: [racket-dev] new package system collections and conflicts

Sam Tobin-Hochstadt wrote on 11/30/2014 12:52 PM: Are you saying that `data` is some kind of classification of "what this module is about", and in this case specifically, "this module, which is part of some more specific package, happens to be regarding general-purpose data structures, so we're

Re: [racket-dev] new package system collections and conflicts

On Sun, Nov 30, 2014 at 12:23 PM, Neil Van Dyke wrote: > >> >> Packages may find it convenient to build and provide reusable >> functionality with many organizational names. This is particularly true of >> "data", as many packages may have useful data structures. >> >> Of course, as such support c

Re: [racket-dev] new package system collections and conflicts

Jay McCarthy wrote on 11/30/2014 12:30 PM: On Sunday, November 30, 2014, Neil Van Dyke > wrote: Jay McCarthy wrote on 11/30/2014 12:13 PM: The documentation cited is making clear that there is NO connection between the name of a package and the

Re: [racket-dev] new package system collections and conflicts

On Sunday, November 30, 2014, Neil Van Dyke wrote: > > Jay McCarthy wrote on 11/30/2014 12:13 PM: > >> The documentation cited is making clear that there is NO connection >> between the name of a package and the provided modules. There is no such >> thing as a package namespace. >> > > I'd really

Re: [racket-dev] new package system and versions

I don't understand this question. The package system doesn't really have a concept of version like you are referring to. The package X is versionless. It is possible to know that your copy of X is different than another's, hence checksums and updating (which should have been called sync, in retros

Re: [racket-dev] new package system collections and conflicts

Jay McCarthy wrote on 11/30/2014 12:13 PM: The documentation cited is making clear that there is NO connection between the name of a package and the provided modules. There is no such thing as a package namespace. I'd really like there to be. For third-party packages. Packages may find it

Re: [racket-dev] new package system and versions

Although I object to some of your characterizations of the difference between PLaneT and the new package system, it's fair to say that PLaneT provides better support to package authors for creating new APIs that are intended to replace (but coexist with) old APIs. I think the answer to that proble

Re: [racket-dev] new package system collections and conflicts

I do not think we should change the example. I do not want people to falsely believe that they can any expectation of the modules provided by a package from its name. In particular, your comment about this being "strange" is not supported by the package system's promises. Jay On Sunday, November

Re: [racket-dev] Splitting the Racket repository

On Sat, Nov 29, 2014 at 8:16 PM, Eli Barzilay wrote: > On Sat, Nov 29, 2014 at 7:14 PM, Sam Tobin-Hochstadt > wrote: >> >> All the history for the code has been preserved, and for code that >> dates back before 2005, the history is extended back to the original >> CVS repository. See https://gith

Re: [racket-dev] new package system collections and conflicts

The documentation cited is making clear that there is NO connection between the name of a package and the provided modules. There is no such thing as a package namespace. Packages may find it convenient to build and provide reusable functionality with many organizational names. This is particularl

Re: [racket-dev] new package system collections and conflicts

Sam Tobin-Hochstadt wrote on 11/30/2014 10:55 AM: Another example where this happens (and in a way that couldn't be fixed by combining packages) is with typed versions of libraries. If I release a package with the collection `foo`, and then someone else produces a typed version of it, that will p

Re: [racket-dev] new package system collections and conflicts

On Sun, Nov 30, 2014 at 10:44 AM, Matthew Flatt wrote: > > There are plenty of real examples where it's sensible for different > packages to introduce modules in overlapping collections, though. > Sometimes, it's because different packages implement different facets > of a conceptual whole, such a

Re: [racket-dev] new package system collections and conflicts

We should change that example. It would indeed be strange for package named "tic-tac-toe" would introduce a `data/matrix` module, and the documentation really shouldn't suggest that it makes sense for a package to introduce overlaps that are not reasonably expected from the package name. There ar

[racket-dev] new package system and versions

Any chance of revisiting the new package system's stances on versions -- specifically, on the two issues: 1. Can subsequent versions of a named package (which has an identity) be non-backward-compatible? 2. Can a Racket setup (and even an individual program) have multiple versions of a package

[racket-dev] new package system collections and conflicts

Given the example from the documentation, of the `tic-tac-toe` package and "conflicts" (quoted at end of this email), instead, why isn't the norm to do: (require tic-tac-toe) Or, when necessary: (require tic-tac-toe/matrix) Why, when one installs a package named `tic-tac-toe`, would