Version 3.4.0-beta

[slozier]

Things left to do for the release:

• Release DLR 1.3.2 and bump to nuspec
• Finish and merge Filter undefined property getters/setters #1417 and Introduce NotNoneAttribute alias #1420
• Update installer?
• Document breaking changes related to PEP 237 -- int/long Unification #52
• Prepare release notes (special mentions: f-strings, venv, int/long unification, anything else?)
• Prepare website update with release info
• Testing
• Other stuff?

@BCSharp Any potential PRs you'd like to squeeze in before a release? Can you think of anything else?

[BCSharp]

I have still a few fringe items from the int/long unification, but nothing that has to land specifically before the release. If something does, fine, otherwise it can be done simply during regular development.

I am going to bump up the priority of documenting the changes (which till now sat at the bottom of the int/long list). I don't expect any more changes visible from the user side.

I can't think of any other stuff that may be needed.

[BCSharp]

The milestone page shows #1209 as required for 3.4-beta.

[slozier]

The milestone page shows #1209 as required for 3.4-beta.

Yeah, apparently I thought it would be helpful with some IO issues people were having - but I don't remember what my idea was so we can probably punt it back to 3.6.

[BCSharp]

Maybe this release is also a good moment to modify the version string reported with commandline option -V? On macOS I get

IronPython 3.4.0 3.4.0.0 on .NET 6.0.1

The "3.4.0.0" seems superfluous and does not match the version reported by the interactive interpreter, which on the first line displays

IronPython 3.4.0b1 (3.4.0.0010)

[slozier]

I tweaked it to output:

IronPython 3.4.0b1

CPython doesn't seem to have anything extra (like the (3.4.0.0010)) so I kept it short, but if you think it might be useful we can add more info.

[BCSharp]

One of the tools I am using (pylint?) runs the configured python with -V and parses the output to determine which syntax it should support. It skips the first word and then decomposes the rest. I don't know if it can handle letters in the version string, I suppose so, since it is only interested in major.minor, but I will check if it works tomorrow.

Having brief info which .NET is being used was convenient. In a way, .NET is an extension of StdLib, seen from the IronPython's perspective. Do you know what Jyton outputs?

[slozier]

One of the tools I am using (pylint?) runs the configured python with -V and parses the output to determine which syntax it should support. It skips the first word and then decomposes the rest. I don't know if it can handle letters in the version string, I suppose so, since it is only interested in major.minor, but I will check if it works tomorrow.

Python outputs letters as well (e.g. Python 3.11.0a7) so I hope it works. 😄

Having brief info which .NET is being used was convenient. In a way, .NET is an extension of StdLib, seen from the IronPython's perspective. Do you know what Jyton outputs?

Not sure about Jython, but PyPy has the following output:

Python 3.7.9 (7e6e2bb30ac5, Nov 18 2020, 12:05:16)
[PyPy 7.3.3-beta0 with MSC v.1927 32 bit]

[slozier]

Our issue template suggests running ipy -V to get the version info so it might indeed make sense to have the full header:

IronPython 3.4.0b1 (3.4.0.0010)
[.NETFramework,Version=v4.6 on .NET Framework 4.8.4470.0 (64-bit)]

[slozier]

Ahhh, Python has -VV (since 3.6) to get more info:

Python 3.11.0a7 (main, Apr  5 2022, 21:27:39) [MSC v.1929 64 bit (AMD64)]

[BCSharp]

This is perfect now! 👍

[BCSharp]

And now for something completely different...
Why is net5.0 and net6.0 not being packaged in the zip file?

[slozier]

And now for something completely different... Why is net5.0 and net6.0 not being packaged in the zip file?

Answer to that is simple, because they're being excluded. 😉 Reason for exclusion is simple - they're essentially identical to the .NET Core 3.1 DLLs. I don't mind including .NET 6 if you think there's value (probably a good idea since .NET Core 3.1 support is ending in December). Though .NET 5 support is ending on May 8th(!) so I would not bother with it. Might be worth including .NET 6.0 in NuGet as well (though .NET Core 3.1 assemblies should still work so there's not much benefit...)

[BCSharp]

they're essentially identical to the .NET Core 3.1 DLLs

Is it still true since the #if NET code blocks?

I would not bother with .NET 5 either, but having .NET 6 would be useful, at least could prevent questions like "where are .NET 6 assemblies?..." 😉 Even if the WPF DLLs are the same, I would still include them. Maybe the zip format has some options to deduplicate files.

I got this question myself when I quickly wanted to grab this PR's binaries from GiHub CI so that I did not need to mess up my working dir with a checkout and build. First tried the MSI installer, but it only installs ipy for net46, right? Then looked into the zip and found .NET 6 "missing". Which makes me now wonder: what is the recommended way (on Windows) to install a stand-alone IronPython for .NET 6 with WPF support?

[slozier]

they're essentially identical to the .NET Core 3.1 DLLs

Is it still true since the #if NET code blocks?

No it's not true anymore, though most branches are perf related there are some differences (in particular the missing Int32Ops.GetBitLength which is why I would have preferred a reflection based approach).

I would not bother with .NET 5 either, but having .NET 6 would be useful, at least could prevent questions like "where are .NET 6 assemblies?..." 😉 Even if the WPF DLLs are the same, I would still include them. Maybe the zip format has some options to deduplicate files.

Alright, I'll add it to the list.

I got this question myself when I quickly wanted to grab this PR's binaries from GiHub CI so that I did not need to mess up my working dir with a checkout and build. First tried the MSI installer, but it only installs ipy for net46, right? Then looked into the zip and found .NET 6 "missing". Which makes me now wonder: what is the recommended way (on Windows) to install a stand-alone IronPython for .NET 6 with WPF support?

There isn't one - best you can do is download the zip and run the .NET Core 3.1 version with the .NET 6 runtime (if you have both installed you can force .NET 6 with --fx-version or --roll-forward). A solution I've thought about is using .NET global tools to install the .NET 6 version which seems preferable to an MSI based approach.

[BCSharp]

A solution I've thought about is using .NET global tools to install the .NET 6 version

I did some reading on dotnet tool and it seems indeed preferable esp. since it allows to set any target directory. So I, as Admin, could even install IronPython in C:\Program Files\IronPython 3.4 if I wanted (not that I wanted). Or install it locally in a project, in effect as a venv. The last one is appealing, since venv is still not working well.

Is this something you wanted to support in this release (as "other stuff") or are thinking about some future point?

[slozier]

The last one is appealing, since venv is still not working well.

Which part of venv is not working for you? I managed to set up an env from the MSI install.

Is this something you wanted to support in this release (as "other stuff") or are thinking about some future point?

Something for the future I think - I haven't looked into it at all and don't want to hold back this release longer than necessary.

[BCSharp]

Which part of venv is not working for you? I managed to set up an env from the MSI install.

I should have clarified that I was talking about ipy for .NET 6 (that's why dotnet tools was such an interesting alternative). Creating an environment succeeds, but the environment is not usable because ipy.runtimeconfig.json is not copied and running ipy crashes. Also .config and .xml files are missing though I could not determine if this was something important. At least the 'xml files are just pure documentation which is not used by ipy, I suppose. I was doing all tests on Windows, though my ultimate goal is to be able to use venv with ipy/.NET6 on macOS & Linux.

I don't know how to work around the issue without modifying venv in StdLib. If this is what is ultimately required, maybe it would be good to submit a patch to venv upstream. It won't help ipy 3.4 (or even 3.6) but eventually we will catch up.

I did some tests with setting an env from the MSI install and it seems to work OK, (both with and without option --system-site-packages, but fails when I use the newly created environment to create an offspring env (need to use --without-pip) to succeed). I consider it a minor issue since creating an env dependent on another env is poor practice (in my opinion).

---

Thanks for including .NET6 DLLs!

[slozier]

I don't know how to work around the issue without modifying venv in StdLib. If this is what is ultimately required, maybe it would be good to submit a patch to venv upstream. It won't help ipy 3.4 (or even 3.6) but eventually we will catch up.

I don't mind patching venv if that's what it takes. Something like seems to do the trick on Windows (if I also include ipy.exe):

def include_binary(self, f):
    if f.endswith(('.pyd', '.dll')):
        result = True
    else:
        if sys.implementation.name == "ironpython":
            if f.endswith(".runtimeconfig.json"): return True
        result = f.startswith('python') and f.endswith('.exe')
    return result

[slozier]

@BCSharp I'll probably try and do the release this evening - if you have anything else just let me know and I can hold off.

[BCSharp]

I have no other points. From my side, the release is good to go.

[BCSharp]

Hmm, when I run /.make package locally on Windows, I get now a long series of errors that look like

C:\Code\ironlang\ironpython3\Package\msi\obj\Release\_IronPythonStdLib_dir.wxs(581): error LGHT0103: The system cannot find the file 'C:\Code\ironlang\ironpython3\Package\Release\Stage\IronPython-3.4.0-beta1\Lib\collections\__pycache__\__init__.cpy
thon-37.pyc'. [C:\Code\ironlang\ironpython3\Package\msi\IronPython.Installer.wixproj]

The MSI installer is not created, nor is the zip file. I do have Python 3.7 installed system-wide, but the package target was working without problems with 3.4.0-alpha1.

[BCSharp]

OK, I deleted the whole work area and cloned a fresh one, and everything works now. I wonder that that was about.

[slozier]

Glad you figured it out. Release is out (though I need to redo the stdlib nuget package since I forgot to update the dependency... really need a checklist)