Yesterday, Matthew Flatt wrote:
> We already have a system for constructing a script that can move
> files around and adjust content as needed: git.
The script that I'm talking about *would* be in the repository, of
course. It will essentially become a replacement for the distribution
specs -- with the following differences:
* Much less sophisticated, since it'll be just verbatim paths
* Enforced via a package-aware build.
* Easily translated into a git operation to split the monolithic
repo.
And with all of that, it is a truly gradual change -- allowing work on
the package front to proceed without disturbing anyone's work
environment until the repositories are physically split.
> As long as some of us are trying to write that script while others
> are changing the existing directories and files, there will be
> collisions.
That's true, but the downside of changing the structure and having
files and directories move post structure change will completely
destroy the relevant edit history of the files, since it will not be
carried over to the repos once it's split.
Meta-note: I'm not arguing this as something that I strongly care
about personally. I'm fine with nuking the whole history and start
from fresh repositories post-split. I'm just trying to make the
damage explicit for those who do care about keeping that history.
In addition, I'm trying to make the move to packages as painless as
possible for people -- your suggestion introduces three big changes:
(a) structure change, (b) packages, (c) repository+structure change;
and my suggestion eliminates (a), and a large part of (c) which will
be a byproduct of (a). The reason that I think it makes more sense is
that it allows package-based builds to start as soon as possible (even
now, if the build is working with it), without waiting for anyone to
adapt anything.
> I want to minimize conflicts and maximize the number of people who
> can help refine the package structure.
The only point of loss that I see is the equivalence of the
"check-dists" as a test in drdr -- but even that is completely minor,
since drdr itself would also switch to package-based builds, and
therefore dependency problems would still get reported by drdr.
What other conflicts (ones that won't be detected by nightly or drdr
builds) do you see?
> I think a lot of people on this list are eager to contribute to the
> shift into packages. As someone close to the new structure, I'm
> telling you my best guess at how you can help and in be in a
> position to help more: let us switch the repo sooner rather of
> later.
As another meta-point: I'm probably at the top 2% of eagerness to
switch. The current distribution thing is full of stuff that I would
be very happy to see gone; the package-level dependency problems are
things that I have been complaining about for years (and usually I'd
be the only one to do so, and get some weak support only after huge
emails trying to explain the future damage). In addition to that,
back when the general direction was to keep the single repository as a
place for all of the "main" package sources I sighed at the prospect
of having the distribution-spec linger on as a specification of
package splitting -- and I preffered to move into a split-by-directory
structure to simplify things; so the move to separate repositories is
something that is way more appealing to me. In short, I *very* much
want this to happen, and I want it to happen as soon as possible.
And this is exactly why I've made this suggestion: it allows an
immediate switch. No need for any kind of convincing or discussion.
As long as people agree on the end result of splitting into
repositories, the package work continues as planned, unstoppable and
undelay-able by people who are not dealing with packages.
(And as a side note: even in the imaginary case that eventually
there's some anti-package or anti-repo-split revolution, nothing is
lost, since the result is still a better build + distribution
process.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
