[Ironpython-users] Splitting up the IronPython repo

[Vernon D. Cole]

+1 on splitting.

I have been trying to quietly lobby for returning IronPython into the
Ubuntu distribution.
Splitting out Ruby would be a helpful step.



On Wed, Jan 22, 2014 at 3:20 PM, Doug Blank <doug.blank at gmail.com> wrote:

> +1 for these plans! I think this split will be good for the dlr, which
> hasn't (so far) been used as much as it could.
>
> BTW, (and this is a small point) even though IronRuby is dead and was
> never complete, it is still functional for some purposes. So, if it is
> possible without major time commitments to keep it at least as-is,
> that would be useful for our purposes.
>
> Thanks for all of your work, especially for thinking about the big picture!
>
> -Doug
>
> On Mon, Jan 20, 2014 at 4:09 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
> > One of the big issues with working on IronPython is the size of the
> > git repository (specifically https://github.com/IronLanguages/main) -
> > git does not like really big repos, especially on Windows. Part of the
> > problem is that the repository includes:
> >
> > * The DLR
> > * IronPython
> > * IronRuby
> > * Two copies of the Python stdlib
> > * The Ruby stdlib
> > * WiX
> > * and a bunch of reference assemblies
> >
> > Even on a fast machine, 'git status' takes several seconds to return.
> > I believe this is because it was originally a TFS repo, which can
> > scale to handle bigger repos by using a bigger server. With git that
> > option doesn't exist - if the repo is too big, the only option is to
> > split it up.
> >
> > I've created two repos - https://github.com/jdhardy/dlr and
> > https://github.com/jdhardy/ironpython-only - that contain just the DLR
> > and IronPython, respectively. In them, git calls are nearly
> > instantaneous, which makes working with it a lot less painful.
> >
> > There are other advantages - the DLR can get its own release cycle and
> > packaging, and IP can then depend on a specific version of the DLR.
> > Each project has a modified version of the IronPython build system
> > that makes it easy to build for other platforms (iOS, Android, Win8,
> > etc. - they still need to ported and tested, but the builds are
> > easier).
> >
> > I did most of the work using Mono/xbuild, so I know it works there
> > (except for a bug in Mono's .NET 4.5 support), but it has some errors
> > on Windows that I need to sort out.
> >
> > Once I get my Windows box back and get some time to fix the few
> > remaining issues, I'll move the repos to the IronLanguages account and
> > use them for development of a real DLR release and IronPython 3.0. Any
> > more 2.7 releases will come out of the existing repo.
> >
> > One downside is that copying patches between 3.0 and 2.7 is going to
> > be extra work, but 3.0 will solve so many problems with strings that I
> > think it will quickly become the more common target. In general Python
> > 3 momentum is picking up so it's a good time (some recent
> > hand-wringing notwithstanding) to try and have IronPython 3 in the
> > right spot at the right time.
> >
> > I haven't really addressed IronRuby because, for intents and purposes,
> > it's dead.
> >
> > All of that said, if anyone has any objections I'd like to hear them.
> > The split repos work well for me but I'm curious if others prefer the
> > combined repo.
> >
> > - Jeff
> > _______________________________________________
> > Ironpython-users mailing list
> > Ironpython-users at python.org
> > https://mail.python.org/mailman/listinfo/ironpython-users
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140123/12eed4ca/attachment.html>