sogno-platform / cimgen Goto Github PK

Bug
CIMgen v3 fails at line 420 using Docker

Traceback (most recent call last):
File "/CIMgen/build.py", line 16, in
CIMgen.cim_generate(schema_path, args.outdir, args.cgmes_version, langPack)
File "/CIMgen/CIMgen.py", line 685, in cim_generate
parsed = _parse_rdf(parse_result, version)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/CIMgen/CIMgen.py", line 420, in _parse_rdf
short_package_name[profile_name] = short_profile_name
^^^^^^^^^^^^^^^^^^
UnboundLocalError: cannot access local variable 'short_profile_name' where it is not associated with a value

To Reproduce

Steps to reproduce the behavior:
1: docker build -t cimgen -f Dockerfile .
2: export SCHEMA_DIR='/home/cimgen-master/cgmes_schema/CGMES_3.0.0'
3: export OUTPUT_DIR='/home/cimgen-master/CGMES_3.0.0_python'
4: docker run -v ${OUTPUT_DIR}:/cgmes_output -v ${SCHEMA_DIR}:/cgmes_schema cimgen --langdir=python

Expected behavior
Correct me if I am wrong, if I understand correctly CIMgen generates classes for CIMpy?

Docker on Linux

• OS: openSuSe Leap 15.5
• Docker: version 24.0.5-ce

Many potential customers are using Java. It would be nice for our code to be available to them.

Context

When running the generation for a class the templater is fed with the class_details dictonary. Within there is a list of attributes (class_details["attributes"}]`) that describe the attributes. This attribute description contains a key dataType.

Problem

The value of this key seems to be inconsitent or the name might be missleading, as for primitives (Integer, Boolean etc.) it does contain the type but for complex types it contains the muliplicity (e.g. M:0..n) for some reason.
This seems to be either:

1. a bug (if muliplicity should never be there) or
2. misleading naming (if it is correct that the multiplicity shows up here).

Either way the contained information is available from other values class_name and multiplicity respectively which both seem to be more consitent and should likely be used instead.

Scope

Other than the generation of a comment in the cpp generation the value from dataType is thus far only used in the modern_python langPack.

@dinkelbachjan we need to add our sign-offs here: https://github.com/sogno-platform/cimgen/blob/master/documentation/past-commits.txt

Probably, the easiest way is to start from the python template and adapt it for the json-ld specification.
One example for CGMES json-ld can be found here.

Is your feature request related to a problem? Please describe.

More automated test = more quality and less work :)

Describe the solution you'd like

Have a look if any of the following CI is interesting for you:
zaphiro-technologies#2

in which case I will be happy to open an appropriate pr to you repo.

Describe alternatives you've considered

Will only merge this CI to our repo and live with that.

Additional context

N/A

The Seconds type is based on Float:

https://cgmes.github.io/CGMES-v2_4_15/EquipmentProfile-v2_4_15-7Aug2014.html#Seconds

Setting the default value to be an integer causes an error parsing values with a decimal place, for example:

https://github.com/cgmes/micro_grid/blob/16dd7feb1f9eced20ec6537d7027889aa294e7df/BaseCase_BC/BE_v2/MicroGridTestConfiguration_BC_BE_EQ_V2.xml#L1343

'Seconds' was added to the list in _set_default in c3868f3

          I would suggest to use  `python:3-alpine`, then the 2 `apk` lines become unnecessary, I think.

Originally posted by @guillaume-alliander in #27 (comment)

Currently, the v3-generated python code from CIMgen and the v3 code in CIMpy differ.

TODO: compare versions, adapt CIMgen so that it generates python code matching the CIMpy repository.

I would like to adapt this library to generate React components, as an alternative to using handlebars in Pintura

The IEC 62325 schema files are available here: https://www.entsoe.eu/publications/electronic-data-interchange-edi-library/
This issue depends on #7.