pyecore/setuptools-pyecore

A setuptools command for generating Python classes from Ecore models

setuptools-pyecore's Issues

Code generation overwrites static sample code

If the library.ecore model part of the sample project is generated it overwrites the checked in __init__.py file. The library metamodel should be generated into model folder of the project.

Add verbosity user option

A user option to configure the verbosity of the PyEcoreGenerator should also be provided in setuptools-pyecore. There exist three levels:

• warning
• info
• debug

The user should be able to pass this levels in a setup.cfg and on the command line.

Migrate build-jobs to travis-ci.com

From a build perspective setuptools-pyecore is a legacy project which is still hosted on travis-ci.org. The guys from Travis CI are currently replacing the legacy travis-ci.org platform with the new travis-ci.com platform (see Open Source on travis-ci.com). In Q3 also legacy projects will be migrated to travis-ci.com. In this ticket the migration should be tracked and necessary configuration changes (e.g. check and status api) should be applied to this project.

Clean up of resource throws exception in case resource couldn't be loaded

The _load_ecore_model tries to remove a Resource in every case. Also if a model couldn't be loaded (e.g. because of an invalid content) the removal of the Resource from the ResourceSet will be triggered. This results in the following exception:

Traceback (most recent call last):
  File "setup.py", line 22, in <module>
    long_description=open('README.md').read(),
  File "<path>\venv\lib\site-packages\setuptools\__init__.py", line 140, in setup
    return distutils.core.setup(**attrs)
  File "C:\DevTools\Python36\lib\distutils\core.py", line 148, in setup
    dist.run_commands()
  File "C:\DevTools\Python36\lib\distutils\dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "C:\DevTools\Python36\lib\distutils\dist.py", line 974, in run_command
    cmd_obj.run()
  File "<path>\.eggs\setuptools_pyecore-0.1.0-py3.6.egg\setuptools_pyecore\command.py", line 131, in run
    with self._load_ecore_model(ecore_xmi_file) as resource:
  File "C:\DevTools\Python36\lib\contextlib.py", line 81, in __enter__
    return next(self.gen)
  File "<path>\.eggs\setuptools_pyecore-0.1.0-py3.6.egg\setuptools_pyecore\command.py", line 117, in _load_ecore_model
    rset.remove_resource(resource)
UnboundLocalError: local variable 'resource' referenced before assignment

Required dependencies aren't installed

During installation of setuptools-pyecore the following required dependencies aren't installed:

• pyecoregen
• pyecore

Deploy setuptools-pyecore to PyPI and GitHub releases

The deployment of setuptools-pyecore should be automated. The package should be deployed to the following web services:

• GitHub Releases
• PyPI

For GitHub Releases the organization account of pyecore should be used. Only a binary distribution (wheel package) should be deployed.

For PyPi the personal account of ferraith should be used. A source and a binary distribution of setuptools-pyecore should be deployed.

Redesign user interface

The current user interface isn't as intuitive as it should be to easily configure the code generation of multiple Ecore models. This is mainly because of the limited feature set provided by setuptools and distutils to specify config parameters (see config file doc).

Also the current user interface lacks the possibility to specify several models with equal names.

To overcome this limitations and simply the configuration the current user interface should be redesigned. The configuration should be split up in a basic configuration for default values (e.g. an output folder) and a model-specific configuration.
Basic configuration should be possible on the command line and in a config file. Model-specific configuration (e.g. specific output-folders, user-models, ...) should be limited to config files in the first place.To be as close as possible and compatible to the - ini like - configuration language used by setuptools it should be still possible to use the standard python config parser.

A very basic configuration file should look like this:

# default configuration
[pyecore]
output=gen
auto-register-package=True

# model specific configuration
[pyecore:library]
ecore-model=/path/to/library.ecore
output=gen/library
auto-register-package=False

Model specific configurations should override the default configuration. The second part of the section name (e.g. [pyecore:library] ) can be freely chosen by the user and isn't bound anymore to the root package of the Ecore model.

Improve documentation

Actually the documentation of setuptools-pyecore focuses on integration aspects and usage without giving the user an idea of the behavior. This aspect should be described in more detail.
Additionally a table of content should be added at the top of the project to simplify navigating in the documentation.

Sanity check for user input

The user input passed on the command line or in config file should be validated by setuptools-pyecore. A sanity check for the following parameters should be added:

• user-modules
• output

If the path to a output directory or to a user module isn't valid (e.g. doesn't exist) a warning should be thrown. For an user-module the code should still be generated without passing the user-module path to the EcoreGenerator. For an invalid output path the default output folder should be used.

Refactor project structure

Move library sample from example to samples/library folder

Add logging output

The user isn't informed which model is generated by pyecoregen. If several models were found by setuptools-pyecore or the user specified more than one model the user doesn't know about the model which is currently generated. This gets more problematic if the generation fails for one of the found models but the user don't know which model is the faulty one.

Before the model generation is triggered the distutils logging framework should be used to print a user friendly generation message.

Refactor default output directory

If the user doesn't pass a default or model specific output path the package source directory will be used as a fallback. This behavior should be changed for two reasons:

• In case multiple equally named Ecore models are generated the output path isn't unique. pyecoregen will overwrite the generated code
• Intuitively the user will expect that the generated code is placed in parallel to the Ecore XMI file and not in the root folder of the package.

User modules doesn't have a regular path

setuptools-pyecore handles user models as regular files with a valid windows or posix paths. This assumption is wrong. From pyecoregen doc:

If specified, the given string is interpreted as a dotted Python module path. E.g. --user-module my.custom_mod will make the generated code import mixin classes from a module my.custom_mod.

To fix this problem user modules passed on the cli or defined in a setup.cfg file shouldn't be handled anymore as paths. A simple string is sufficient.

library model contains invalid content

The content of the library.ecore model is invalid. The content consists of html data.

Generate code from a Ecore model

In this ticket the core functionality of setuptools-pyecore should be implemented. In the run method of the PyEcoreCommand a new PyEcoreGenerator should be instantiated. User options should be passed to this instance and the Python Code of the Ecore model should be generated.

Add Python 3.7 support

Add Python 3.7 support as soon as it is supported by Travis CI.
See the upstream issue travis-ci/travis-ci#9815

Looks like Travis CI won't support Python 3.7 in default images anymore. The official workaround is to switch to xenial and enable sudo like described here.