+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.bl...@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 <jdha...@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@python.org > > https://mail.python.org/mailman/listinfo/ironpython-users > _______________________________________________ > Ironpython-users mailing list > Ironpython-users@python.org > https://mail.python.org/mailman/listinfo/ironpython-users >
_______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
