Skip to content
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

Packages #3

Open
2 of 6 tasks
prisae opened this issue Aug 7, 2021 · 5 comments
Open
2 of 6 tasks

Packages #3

prisae opened this issue Aug 7, 2021 · 5 comments
Labels
new packages Adding packages for additional programming languages

Comments

@prisae
Copy link
Member

prisae commented Aug 7, 2021

Packages

The library contains all the filters as plain text files. However, we want to add CI-scripts (in /packages/language-name/) which create deployable packages for different programming languages.

Planned so far:

@prisae prisae added the new packages Adding packages for additional programming languages label Aug 7, 2021
@prisae prisae pinned this issue Aug 7, 2021
@prisae
Copy link
Member Author

prisae commented Aug 9, 2021

A first version of Python is implemented. However, it might not be the best way yet. What is definitely still missing:

  • Testing for the Python package
  • conda-forge deployment (only pip at the moment, a problem with setuptools_scm)

@kerrykey
Copy link
Collaborator

kerrykey commented Aug 14, 2021

A first version of a Julia package is implemented. A few remaining steps are needed (and beyond my current know-how):

@prisae
Copy link
Member Author

prisae commented Aug 17, 2021

It might be helpful to add some metadata to the packages. E.g., in Python, something like

def key_201_2012():
    ...
    return base, j0, j1

key_201_2012.returns = ['base', 'j0', 'j1']

This would make it easy to programmatically check what it returns, and if it can be used for a given use case.

E.g.

if not 'j0' in chosen_filter.returns:
    raise ValueError('This application requires a j0-filter; please choose another filter')

or similar.

Or add dicts, similar to the caching, with

dlflib.hankel.j0 = ['wer_201_2018', 'gupt_61_1997', ...]
dlflib.hankel.j1 = ['wer_201_2018', 'gupt_47_1997', ...]
dlflib.hankel.j2 = [??]  # There are j2 filters

The issue is that not all filters have all attributes. But then, not all filters are good for a given application. Anyhow, a code must be able to fail gracefully for filters which do not work at all because they have missing values.

Once we start using libdlf in real-world applications it might become apparent what more is needed.

@kerrykey
Copy link
Collaborator

Yeah, I agree that having the metadata like function returns would be useful, especially for external testing and other automated functions. Otherwise such codes would have to parse a docstring to see know the contents of a returned tuple.

@prisae
Copy link
Member Author

prisae commented Aug 22, 2021

In the Python package, the filter functions have now an attribute values, which lists the returned values (without the always returned base). Example:

>>> import libdlf
>>> libdlf.hankel.wer_201_2018.values
['j0', 'j1']

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new packages Adding packages for additional programming languages
Projects
None yet
Development

No branches or pull requests

2 participants