[racket-dev] experiment reorganizing the repo into packages

Yesterday, Matthew Flatt wrote:
> At Mon, 3 Jun 2013 10:36:51 -0400, Eli Barzilay wrote:
> > (BTW, a possible source of confusion: I'm assuming that
> > distribution must be done via archives and not via repository
> > specs, since there should be some way to put the compiled files in
> > there.
> 
> I don't think that's the right assumption. We want it to have
> packages that combine source with built entities, but I don't think
> we want to require it. Requiring it would break the way GitHub
> repositories are meant to be used as packages.

But they are required for all non-source things anyway, right?  And
given that the plt packages have binary distributions, then they
should be someplace else anyway.

If the sources *do* come from the repository, how does it get a
specific version that corresponds to whatever was distributed in
binary form?  If I have v1.2.3 installed, and it came with web server
as precompiled zo files, and I install the source -- how do I get that
specific version of the source?  The only thing I can think of is
relying on tags but that's a bad assumption since it assumes that
package owners keep and maintain the proper tags, and the release
should come with adding tags in all of these repos -- and that
contradicts letting people do whatever they want to do.

This is going further off-current-topic, but when I talked to Ryan
about possibilities for revising the release process, I thought that
the thing that makes most sense is that at the branch creation time
(which still happens as usual in the core package repo), package
owners hand over a sha1 that corresponds to their recent version.
That gets used by the build (possibly via a meta-repo that has these
sha1s as submodule specifications) script which gets these versions to
build the packages.  The equivalent of me making a "merge this commit"
request is now turning into asking Ryan to change my sha1 to a newer
one, and Ryan can now use a diff between the two sha1s to review the
changes that I made.  The main point here is that it makes the package
repositories be completely independent: package maintainers can keep a
`release' branch and release tags if they want, or they can avoid the
whole thing.  And in fact I think that the much more common case would
be to not having a release branch etc.

But going back to the on-topic point: this whole plan assumes that the
sha1 is what gets used to pull the content and build zipped package
archives.


> > You've mentioned at some point a "binary catalog" which seems
> > unnecessary to me, but maybe there's something I don't get here.)
> 
> Yes, binary packages are another way to address the underlying
> issue.
> 
> I'm going to try to synthesize the progress and discussion so far in
> a new message, and hopefully I'll managed to explain binary packages
> this time around.

It would be good to take the above into account, as another reason for
doing this which is independent of actual binary files.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!