Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
GitHub or Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
The IronPython that is bundled with Mono on the Mac does not include any Python built-in modules. This was observed in Mono 2.10.6 and 2.10.8 for Mac:
IronPython 3.0 (188.8.131.52) on .NET 4.0.30319.1
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named os
Duncan, any updates?
Bump. Problem is still there:
> ipy -V
IronPython 3.0 184.108.40.206 on 3.10.0 ((detached/e204655 Mon Oct 13 08:50:28 EDT 2014)
As of today, latest stable release is 2.7.4, and current beta is only 2.7.5-beta2.
This seems to work now on Mono 4.4:
> alexander:~$ ipy
> IronPython 3.0 (220.127.116.11) on .NET 4.0.30319.42000
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import os
> >>> os.name
Actually I am having difficulty finding out what exact version of Ironpython is shipped with the Mono binaries (does not seem to be in the source?) and how it was built, since I am having problems building ironpython3 on linux, but using those from windows mono seem to work. Care to enlighten me?
@Hin-Tak Leung: according to https://github.com/mono/bockbuild/blob/master/packages/ironlangs.py (which is the script we're using to build the package) we're shipping commit de63773744ccf9873c1826470730ae0446fd64d7.
@Alexander Köplinger : Thanks for the notes! I have had that script in my radar but it is somewhat surprising - it claims to be 3.0 on -V but rather behind (nearly 5 years old). It is 577 commits behind master and 614 behind ipy-2.7-maint (and 130 from the last common ancestor with ipy-2.7-maint) as of now. It is also a bit surprising it claims to be 3.0 but did not come from git://github.com/IronLanguages/ironpython3.git .
I tried git://github.com/IronLanguages/ironpython3.git and had some difficulty building it; and most current activity seems to be on git://github.com/IronLanguages/main.git:ipy-2.7-maint - would it make sense to switch to git://github.com/IronLanguages/main.git:ipy-2.7-maint or one of its release tags instead?
@Hin-Tak Leung: if you look at the AssemblyVersion.cs from the commit we're using then it is 3.0: https://github.com/IronLanguages/main/blob/de63773744ccf9873c1826470730ae0446fd64d7/Languages/IronPython/AssemblyVersion.cs
I agree that it is quite old, can you please file a new bug for upgrading as this doesn't have anything to do with this issue?
Thanks - bug filed.
About the versioning - I came to this bug report initially when I was searching for any version info of the bundled ironpython - this bug report was the only find.
ironpython 2.6 was a bit clearer the version has nothing to do with python version:
$ mono bin/ipy.exe -V
PythonContext 2.6.10920.0 on 4.2.2 (Stable 18.104.22.168/996df3c Sun Feb 14 19:54:12 GMT 2016)
(I am using ironpython 2.6 as it was the last release which supports a dotnet v2 runtime).