Skip to content

Access klayout __version__ when loaded as python module #1271

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
qpavsmi opened this issue Feb 1, 2023 · 7 comments
Closed

Access klayout __version__ when loaded as python module #1271

qpavsmi opened this issue Feb 1, 2023 · 7 comments
Milestone

Comments

@qpavsmi
Copy link

qpavsmi commented Feb 1, 2023

It would be convenient for us if we could access the version string of the klayout module that is in use. A lot of python modules provide access through the use of __version__ member, I think this could be useful for klayout as well.

This might already be available and I just didn't read the klayout docs carefully enough :D But as far as I'm aware there is only the pya.Application.version member, which is not available when klayout is imported as a python module without running the klayout executable.

@qpavsmi
Copy link
Author

qpavsmi commented Feb 1, 2023

Hi, spent an extra 5 seconds reading about importlib. It has version method for any module that is in use, which is sufficient for our needs :D This issue doesn't need to stay open for our sake

@klayoutmatthias
Copy link
Collaborator

Exactly. Honestly I thought that if I do setup.py a favour and tell it the version, it would also be able to return it to me. Apparently it took until Python 3.8 for this to become true :)

But your remark about pya.Application is valid. This is also true for Qt-less builds (not only Python), so I'll leave the ticket open and create a standard way of getting the version without pya.Application.

Thanks,

Matthias

@klayoutmatthias
Copy link
Collaborator

@thomaslima Thanks for the PR

I found a very simple solution while looking how other projects solve that problem: master...issue-1271

I personally like that the metadata (== version.sh) remains the single source of truth here. Is there an advantage using versioneer over this simple solution?

Thanks,

Matthias

@thomaslima
Copy link
Collaborator

@klayoutmatthias You are right. It's simpler. This is solution number 5 in the following guide: https://packaging.python.org/en/latest/guides/single-sourcing-package-version/

As you can see in the failed tests, the only caveat is that it is only available for python >= 3.8. It's backported as a package called importlib_metadata, so we need to install it for python < 3.8. I took the liberty to push a patch to your branch. Check it out.

@klayoutmatthias klayoutmatthias added this to the 0.28.6 milestone Feb 16, 2023
@klayoutmatthias
Copy link
Collaborator

Perfect! Many thanks!

Best regards,

Matthias

@klayoutmatthias
Copy link
Collaborator

@thomaslima Azure fails with Python 3.6 with

ERROR: Could not find a version that satisfies the requirement importlib-metadata>=1.0; python_version < "3.8" (from klayout) (from versions: none)
ERROR: No matching distribution found for importlib-metadata>=1.0; python_version < "3.8"

I confirmed on Linux with Python 3.7 (3.6 is no longer available) that the approach basically works also for Python < 3.8.

Unfortunately the other Azure jobs terminate with too much CPU time, so it's difficult to say if the problem is specific to 3.6.

@thomaslima
Copy link
Collaborator

I just pushed a commit pinning importlib_metadata's version to 4.8.3. It was the last version supporting 3.6. Let's see if it will pass tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants