Hello,
a few days ago I ran across this:
http://www.kickstarter.com/projects/joeyh/git-annex-assistant-like-dropbox-but-with-your-own?ref=category
and made a symbolic contribution.
However, this project could become one of the convenient options to
distribute ConTeXt, in the sense that it would probably allow sparse
checkouts from git, and we could have one huge git repository and with
some basic scripting on the client side (in the same way as it is done
now with rsync), user could choose to download just MKIV or just the
basic fonts in contrast to a huge collection of fonts that might end
up in that big repository. Basically, git could replace rsync (the
rsync way could stay; this would just add an extra option). At least
that is my understanding, but I admit that I don't have the full
picture in front of my eyes and I would actually be grateful for the
second opinion from other ([not necessarily] git) experts here.
The reason why I'm writing is that by donating the following amounts,
one might be able to ask for additional features if/when needed:
100 $
Help set my priorities for which features are the most important. I
aim to make the git-annex assistant please you right out of the box by
supporting exactly what you need.
250 $
Be my beta tester for the git-annex assistant. You will influence the
project throughout, and will set my priorities for which features are
the most important.
and if this really becomes an important way to distribute ConTeXt, we
could either make some kind of group donation of a few volunteers,
or consider using part of ConTeXt Group funds (as ConTeXt Group was
established exactly for the reason to fund projects that are important
to the community). If that can help ConTeXt users switch to older
version more easily, the requested amounts for funding are more than
reasonable.
This is what the author has answered to one of my question about how I
could let user select which modules to install (module = a collection
of fonts, a collection of mkii-only related files, engine-related
files etc.) out of the whole distribution:
I can think of a few ways to handle the checkout of a specific set of
modules with git-annex.
If there's a text file manifest listing the files in each module, then
something like:
git annex get $(cat 1.manifest 3.manifest 7.manifest ...)
Better, put each module into its own git branch. Then the user can
merge in the branches for modules they want. This has the advantage
that the only files they'll have visible in their git repository will
be for the selected modules.
git merge module/1 module/3 module/7; git annex get
Users would want to do that after every git pull, presumably, so
probably a shell script would be called for.
What I didn't ask is whether Mac or other non-linux systems would also
be supported. Windows seems to be feasible, but not is not guaranteed
to happen:
If I'm funded for a year ($20k), I will spend at least one month
of it in Windows purgatory, making the port happen. No guarantees of
success on this one!
(he is missing less that $1k for that goal though).
---
Actually, my original idea/suggestion was actually slightly different
and would probably not need any additional software to be installed,
but would not necessary be in scope of this project. I'm still looking
for a way to have a smarter rsync server, so that I could use
something like
rsync -av rsync://contextgarden.net/suite/context/@tag:2013.12.13T12:13
texmf-context/
and rsync would then serve files from a particular branch/tag/sha of a
git repository, without the need to have different version of
The biggest problem with everything is that I'm somehow narrow-sided.
I need someone to help me think a bit out of the box and get a broader
picture. To help me decide if one of the above options (patching rsync
server or being beta testers for git-annex) would make sense.
Of course anyone is invited to make his/her own donation to git-annex
independent of whether or not it will make sense for us to use it, but
if there is a consensus that it would be worth using it for the
distribution, we could combine our donations or make a donation from
ConTeXt Group to become the official beta testers.
Mojca
(PS: It is not ready yet and I've been promising it for way too long
already, but the first change that I will do to the distribution will
be the ability to use both current approach as well as a git
repository (without the option to exclude stuff), so that if something
breaks in the middle of a project after ConTeXt update, it will be
trivial to go back in time to any given version of ConTeXt matching
LuaTeX fonts. At the moment going back in time requires at least a
bit of creativity, for example fetching the latest working version of
ConTeXt from existing unofficial Git repository etc.)
___
If your question is of interest to others as
