More pythonic, less system-heavy ?

[asmodehn]

Hi,

I would like to use opengeode without the whole TASTE environment, and if possible with recent dependencies.

Since opengeode is written in python I was hoping to get it to run with minimal changes on my machine, since I use a virtualenv to hold what is related to the python code for this project.

I started making some changes for this there : https://github.com/asmodehn/opengeode/pull/1/files
Feel free to grab what is of interest to you, or let me know if you have any question / concerns / future plans, I can always make a pull request to this repo.

I wish one day I ll be able to install opengeode from pip with just a minimal set of system dependencies.

Cheers!

[maxime-esa]

Hi Alex,
Thanks, I will merge your contribution when you are done with it. Any idea how do deal with ASN1SCC and the antlr3 Python runtime?

It's difficult to use OG separately from TASTE as it requires a runtime to orchestrate multiple SDL processes (and manage the PIDs, the instance creations, the timers, the interfacing with other languages). What is your use case?

[asmodehn]

Hi Maxime, and thanks for the quick answer.

Well, I keep switching between languages, as I usually don't find work that uses the esoteric ones that I enjoy.
Recently I want to dive again into erlang, and as SDL seems to be one of the ways to model software in erlang, I thought it would help me twist my brain the right way, after spending too long writing in imperative languages.

So my immediate usecase would be a SDL diagramming tools as such. Not a generic drawing tool though, as I expect it would help me "thinking" right, and prevent me from "thinking" wrong.

A second step might be some bidirectional direction with erlang code (generate code, or generate diagram from code...), but I'm not sure how far along this road I can travel... but the runtime already seems to match what SDL expects ?

Now for the technical bits :

• antlr3 : it is a python package, and pip can install from a file, so I install it from requirements.txt (generated from requirements.in via pip-tools).
  Moving to antlr4 would help, since we have a pypi package for it https://pypi.org/project/antlr4-python3-runtime/

• asn1scc : It is a more lowlevel package, made with quite different tech stack, and I m not sure how to deal with it just yet... But it is not needed for my first usecase however.
  Is there a way to make it optional ? is that even something worth considering for opengeode ?

The main challenge in my experience dealing with python packages and lowlevel requirements, is that the python world moves much faster, and the expectations of the python users, regarding the "best/easier/usual/proper way to do things" can change quite quickly.
On my side I don't have much idea how TASTE is handling things, and how it wants to evolve, so it might be tricky to keep compatibility with it.

For instance, here I expect dealing with a virtualenv specific to this repo, not the user's one... That is probably expected for my usecase (isolated from the system), but TASTE usecase probably requires access to some system utils and packages (which ones?).

I currently have opengeode starting and I can draw some diagrams, and now I have to learn how to use it to detect these deeper connections to system utils that I may have broken...

So I think if we can have some small issues here, showing how opengeode wants to evolve in TASTE, that would be helpful for newcomers like me, to take it one tiny step at a time. Or is there another issue tracker I can have a look at ?

Thanks for all the help and info you can provide.
Now, I think I ll spend a bit of time looking at asn1scc, to see what I can do with it...

Cheers, and thanks a lot for the work already done here !

[asmodehn]

Useful references : https://packaging.python.org/en/latest/guides/

Quick Updates :

• I do not like the idea of complicating things with asn1scc if it is not required to "use" opengeode, and it is completely different tech stack. Making it a option (automatically detected and enabled in the case of TASTE) seems best from my perspective.
• dependencies available in pip should be installed via pip, so that opengeode itself can work out of the box after a pip install opengeode in any virtual environment.

Two questions are:

• How do we expect the developer to manage the virtual environment ? Imho, the relevant options here are either manually, maybe helped with the Makefile, or via a tool (direnv comes to mind, there are probably others...)

• How do we expect the developer to manage the list of dependencies ? Imho, the relevant options here are either manually pinning everything in requirements.txt, or via pip-tools. Other options seem over-engineered for the job.

Let me know what you think thanks !

[maxime-esa]

One comment on asn1scc: it is a strong dependency for opengeode. You can't make SDL models without ASN.1 data types. Therefore it cannot be made optional.
I think it is possible to package binaries as part of pip installs (e.g. PySide6 includes all the Qt libraries which are not in Python). But I never looked into how to do that.
Having the pip dependency list in requirements.txt is definitely a good idea.
For the rest I am not familiar with direnv and pip-tools ; if you think there is an added value, I won't object!

[asmodehn]

After thinking about this a bit more, the bigger change I'd like to do is moving from a "user" virtual env to a "project" virtual env for opengeode, and all its development dependencies. This way cloning the repo and retrieving dependencies via pip will not impact the user environment. This way, we can leave that potentially unsafe steps to the "install" stage.

In project venv:

• pip install -r requirements.txt
• run as package python -m opengeode
• install in venv pip install -e . and run opengeode
  This is all pure python and not impacting the machine it is running on, nor the user environment it is running as.

The opengeode pip package then becomes installable in any python virtual env, meaning user or system as well, if someone whishes so.

I m not sure how to articulate that with the makefile however... and I think direnv can help. However both tools are messing with the shell in different ways, so I guess we'll see if problems arise...

I ll make a PR to try things out and discuss it, but I think it ultimately comes down to how developers will use the repo...