Python environment

zoodinger

Hello,

I have been using KLayout as a means to parse GDS/OAS files easily and efficiently. So far everything is great, but I have a couple of questions.

1) KLayout doesn't seem to use the proper python environment. I'm using Python Anaconda 2.7, which is prepended to my path, but KLayout picks up a different version. The correct is there a way to fix this without manually compiling KLayout?

2) Using KLayout in non-GUI mode doesn't work in environments that don't have windowing system enabled (e.g. via ssh). Using the mode to completely disable the GUI makes necessary classes not available. For example, we need the LayoutView class to access layer information, but accessing this can only happen through MainWindow (afaik), which is disabled. Is there any way to get the data we need in this mode?

Thanks!

Matthias

Hi,

Regarding 1.):

You mean Windows do you? Basically you're on the wrong track. KLayout comes with it's own Python installation and there are many good reasons for that - specifically on Windows. Given the variety of compilers and runtime environments, matching different binaries is opening a can of worms.

Please also note that KLayout embeds Python and Ruby to allow users to extend the base system. That's the use model supported by the GPL from my point of view. There are severe implications of the GPL: if I'd open KLayout the other way round - for embedding it into your system - doing so will count as "linking against". That means you are basically obliged to publish your own code under GPL too. So unless a license shift happens towards LGPL, externalization of KLayout's functionality is hardly feasible.

In fact, I was actually isolating KLayout's environment against externally installed packages on request. This was required to minimize interactions with other tools that provide their own Python and which caused trouble for the reasons mentioned above.

On Linux there is no such isolation and KLayout shares any central Python and Ruby installation. On Linux, every package (gem, egg etc.) you install immediately becomes available to KLayout too.

Regarding 2.):

That's a limitation imposed by Qt. Even without wanting to show the widgets, I cannot instantiate them without a display. Fixing this will basically mean to decouple from a majority of Qt's API and that is effort beyond I am willing to spend.

If you mean "ssh to Linux" then there may be a simple solution: you can use the Xvfb virtual X11 server to run a program in a display-less environment. For example, on Ubuntu, after having installed the "xvfb" package, you can run KLayout headless:

xvfb-run ./klayout -h

Kind regards,

Matthias

zoodinger

I'm currently using Linux, and it picks up the wrong Python environment (it picks up the one in /usr/lib64/python2.7, but my system is set up to use /usr/share/anaconda2/bin/python). This is not an issue because like you said on Windows it comes embedded with its own environment. So if we want to also support Windows any Python environment will work without requiring any 3rd party libraries.

Regarding the license, I'm using two scripts to deal with the situation. One is passed on to KLayout and the other acts as a bridge between the user, i.e. it calls the klayout executable with the appropriate commands and reads from stdout. Should both of those scripts have their source code available? I was under the impression that only the first script (the one that imports pya and all that) would have to be made public.

Nevermind for 2), I thought it would be an easy fix. The xvfb solution seems good enough, I'll look into it. :)

Thanks again!

Matthias

Hi,

The Python it picks will be the one it was built against. That's related to the actual Python interpreter it uses. So for example if you want to run Python 3 and you system provides 2.7, you need to rebuild it.

But if it's just about pointing it to other python modules, you can either use $KLAYOUT_PYTHONPATH instead of $PYTHONPATH or you set the path inside your script with sys.path.append(...). If these modules are native however, they need to be binary compatible with the Python you built KLayout against (which will be /usr/lib64/python2.7).

License-wise I don't care what scripts run inside KLayout or what scripts you use to drive it. I don't see them being touched by GPL. Please note that other projects with a similar setup may not share this point of view. I myself don't want to restrict the usage. So don't worry. In my reply is was referring to one particular request I receive from time to time: people ask me to provide a library they can use within their scripts to pull in KLayout's engine (like import * from klayout.rba). Such a - hypothetical - library is questionable within GPL.

Regards,

Matthias