[Ironpython-users] Splitting up the IronPython repo

[Jeff Hardy]

On Mon, Jan 20, 2014 at 10:13 AM, Markus Schaber <m.schaber at codesys.com> wrote:
> Hi, Jeff,
>
> Good work, I'm all in favour of it. Splitting DLR, IronPython and IronRuby into different projects is a good thing.
>
> Just some unordered thoughts:
>
> The python standard library could be fetched by the build script directly from the cPython servers (maybe with a few local patches applied until those are included upstream). The same may apply to other dependencies.

One of my stumbling blocks has been the best way to do this. Ideally I
could bring in new versions using a 3-way merge to make it easier to
deal with patches not available upstream.

>
> For the first IronPython 3 release, I suggest that you try to target Python 3.4 directly, and skip the intermediate 3.0-3.3 releases.

Yeah, that's the plan. Targeting 3.0 would be hard because IP already
has the "native" _io module introduced in 3.1. :)

This is also an opportunity to break the correspondence between
CPython and IronPython version numbers, with the caveat that
IronPython will never have a version number higher than CPython.

>
> Also, I think now it's time to hard-code .NET 4 as dependency and drop .NET 2/3 - this will allow us to lots of #ifdefs and some other nasty code.  Also, the PAL concept may be extended to replace some of those #ifdefs (as already mentioned on http://blog.jdhardy.ca/2013/06/ironpython-3-todo.html). In my eyes, the main benefit of this will be that we (hopefully) can get rid of the conditional project references (which are a little PITA because they are not handled well by Visual Studio).

The new projects handle conditional refs a bit differently, and Visual
Studio gets much less confused. Extending the PAL is probably the
biggest architectural change I want to make (in a perfect world
IronPython.dll would be a PCL, but I don't know if that's possible),
but major refactorings there are less time spent on implementing
Python 3 features (and there are only so many hours in a day, sadly).

Right now I think 3.0 should focus on Python 3 features and 3.1 should
focus on better platform support. Python 3 evolves very slowly, so
once we get caught up, there'll be more time to work on other stuff.

>
> For debugging purposes, it may still be handy to have a combined .sln which contains IronPython, DLR and maybe the hosting application, but it should be possible to retain the capability to create such a solution.

Yeah, I've had to do that a few times, so it will wtill be possible if
not supplied. If I can get symbolsource.org integrated with the NuGet
packages it might reduce the need to do that.

- Jeff