How to run SimpleHTTPServer on IronPython on Mono

[Sanghyeon Seo]

I took some time to write this HOWTO:
http://sparcs.kaist.ac.kr/~tinuviel/fepy/howto/simplehttpserver-ironpython-mono-howto.html

IronPython seems to get much less interest than it deserves. This
howto shows how to setup IronPython to use with Mono on Linux and how
to rebuild IronPython from source. It also discusses various patches
to current problems. It also shows that IronPython can run
SimpleHTTPServer today, not a trivial achievement.

Hopefully, more Pythonistas on comp.lang.python will have a look at IronPython.

Here's the excerpt from the howto:

The purpose of this document is twofold: to show how to run
SimpleHTTPServer on IronPython on Mono, and to debunk some myths like:

* IronPython doesn't run on Mono
* IronPython doesn't support Python standard library
* IronPython is a toy

Enjoy!

Seo Sanghyeon

 

[Paul Boddie]

I took some time to write this HOWTO:
http://sparcs.kaist.ac.kr/~tinuviel/fepy/howto/simplehttpserver-ironpython-mono-howto.html

Thanks for spending the time writing this. Whilst I don't run Mono or
anything similar, new Python documentation is surely a welcome thing.

IronPython seems to get much less interest than it deserves.
[...]

The purpose of this document is twofold: to show how to run
SimpleHTTPServer on IronPython on Mono, and to debunk some myths like:

* IronPython doesn't run on Mono

But it does require recent versions, according to the document.
Requiring the latest stuff straight from the revision control
repository is always an inhibiting factor in the adoption of software.

* IronPython doesn't support Python standard library
* IronPython is a toy

I don't think people really believe either of these any more. However,
the IronPython developers haven't really done a good job at explaining
the benefits of their work, or clearing up potential misconceptions.
For example, take a look at the previously-promoted Web site:

http://www.ironpython.com

It's out-of-date and doesn't mention the current Web site, which is a
mere section of some corporate "community" site for .NET: hardly a good
way of promoting something with (potential for) a fairly decent brand
identity.

Then, consider the licensing situation: whilst IronPython appears to
have a fairly permissive licence [1], Microsoft have decided to put it
under their "shared source" umbrella [2], confusing things
substantially, since that label used to mean that you could
conditionally look at Microsoft's code but do little else with it; even
now they promote three licences, one of which being similar but not
exactly the same as the "Shared Source License for IronPython". With
various existing open source licences, particularly the Free Software
licences, you know where you stand almost straight away. Meanwhile,
confusing, marketing-directed labelling only makes people less certain
about what they're getting into and what's being hidden from them.
However, one benefit of Microsoft's desire to simplify their licensing
is that the resulting compatibility with existing licences has had some
tentative recognition [3].

Finally, there's the issue of the platform. I imagine that many people
regard the debate as being over as to whether Mono and other similar
projects independent of Microsoft are genuinely open, now that various
Free Software-oriented GNU/Linux distributions are planning to
distribute Mono, but the Mono developers don't score any publicity
points for having belittled some fairly legitimate concerns about
things like patent claims related to the various "standards" involved.
For what it's worth, nagging concerns about the Java platform's
openness (especially related to the add-on standards like J2EE) still
linger in the open source community.

One other thing, not any fault of the IronPython developers themselves:
I guess it doesn't help that the canonical implementation of Python -
CPython - keeps growing new features which have already left Jython
struggling to catch up. If IronPython users consider themselves to be
part of the wider Python community, is it a good thing that they're
reliant on Microsoft to keep that community from fragmenting?

Paul

[1] http://lists.debian.org/debian-legal/2005/08/msg00089.html
[2]
http://www.microsoft.com/resources/sharedsource/licensingbasics/sharedsourcelicenses.mspx
[3] http://mail.fsfeurope.org/pipermail/press-release/2005q4/000120.html

 

[sanxiyn]

But it does require recent versions, according to the document.
Requiring the latest stuff straight from the revision control
repository is always an inhibiting factor in the adoption of software.

Yes, it's unfortunate, as I wrote on the howto myself. Of course, you
can
use released version of MS.NET for easier install.

Also note that current release (1.1.13.4) of Mono runs and compiles
IronPython 1.0 Beta 1, 2, 3 just fine. Only the latest release (Beta 4)
has problems.

I don't think people really believe either of these any more.

Maybe *you* don't, but take a look at the following thread for example:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/2762f6dfc5f72651

Some quotes:
"It seems, that usage of IronPython is currently limited to Windows
platform"
"However, there isn't e.g. a os-module in IronPython"

Which are, false. (They were false even at the time posts were
written.)

And finally, Ian Bicking said:

I think concrete instructions on exactly how to get
IronPython up and working -- for someone with no .NET experience or
familiarity with that toolset -- would be an excellent way to bring
more attention to IronPython from the existing Python community.

So that's exactly what I tried to do.

IronPython developers haven't really done a good job at explaining
the benefits of their work, or clearing up potential misconceptions.
For example, take a look at the previously-promoted Web site:

http://www.ironpython.com

It's out-of-date and doesn't mention the current Web site, which is a
mere section of some corporate "community" site for .NET: hardly a good
way of promoting something with (potential for) a fairly decent brand
identity.

I am aware of these problems and will discuss this in the mailing list
soon. At least, updating the website and having the public bug tracker
are important. (gotdotnet.com tracker isn't one IronPython team is
using.)

Then, consider the licensing situation: whilst IronPython appears to
have a fairly permissive licence [1], Microsoft have decided to put it
under their "shared source" umbrella [2], confusing things
substantially, (snip)
However, one benefit of Microsoft's desire to simplify their licensing
is that the resulting compatibility with existing licences has had some
tentative recognition [3].
[1] http://lists.debian.org/debian-legal/2005/08/msg00089.html

Do you realize *I* was the person asking for clarification of the
license
on debian-legal mailing list?

If IronPython users consider themselves to be
part of the wider Python community, is it a good thing that they're
reliant on Microsoft to keep that community from fragmenting?

I quite don't get what you are trying to say here.

Seo Sanghyeon

 

[Paul Boddie]

[1] http://lists.debian.org/debian-legal/2005/08/msg00089.html

Do you realize *I* was the person asking for clarification of the license
on debian-legal mailing list?

Yes. And I thereby deduce that you also believe that having Debian
approval would mean a lot for IronPython's acceptance, since the Debian
people are regarded as being the most stringent with respect to Free
Software-compatible licensing in distributions.

I quite don't get what you are trying to say here.

This was about how CPython can get away from other implementations by
adding new features. As we've seen with Jython, if there's relatively
little community interest in keeping other Python implementations
up-to-date, and if there's no sponsor with the manpower on hand to do
the work, then everyone in the CPython camp is busy using such new
features in their code, while everyone else is busy wondering if
they'll ever see such new features. Microsoft seem to be committed to
delivering IronPython, and perhaps if they lose interest the community
will step in and do the work, but in such a situation I feel that the
whole Python community (users of CPython *and* other implementations
combined) will suffer "fragmentation" as CPython speeds ahead and
IronPython lags behind just as Jython has done.

Sure, choosing Jython or IronPython is usually a trade-off between
wanting some of the nice Python libraries and wanting access
respectively to Java and CLR libraries, and perhaps many people using
these implementations don't consider themselves as part of (or primary
members of) the wider Python community; if so, it could be said that
the Python "brand" is somewhat diminished already, since people may be
willing to accept slightly more limited variants of the language, using
implementation-specific libraries where standard library facilities
exist, and generally writing an increasingly divergent dialect of the
language.

Personally, I think that having more implementations is a good thing
for the language, mostly because it leads to new and interesting
technical opportunities, but more engagement and support from the
community "standards legislators" will definitely become necessary over
time to avoid confusion about what is and is not "proper Python",
especially if more people don't arrive at Python via CPython.

Paul