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

setuptools package with server as "extra" #62

Closed
markus1978 opened this issue Sep 26, 2019 · 7 comments
Closed

setuptools package with server as "extra" #62

markus1978 opened this issue Sep 26, 2019 · 7 comments

Comments

@markus1978
Copy link
Contributor

markus1978 commented Sep 26, 2019

Great work on the optimade tools.

Unfortunately, the server implementation brings a lot of dependencies (including Python 3.7?). This way, I cannot use the package out of the box (i.e. git repo) and have to either clone/copy code, or modify the setup, etc.

Would be great, if this had more flexibility and we could use an additional "extra" (similar to dev, e.g. pip install optimade[server]) to make it more modular.

If you agree, I could try to find the time and prepare pull request: #63

@dwinston
Copy link
Contributor

I like the “extras” decomposition idea very much. I imagine it may be hard to extricate the server using this technique, though, as I’m not sure one can specify a different version of Python in the “extras”; I could be wrong. It may be necessary to specify a separate pip package optimade-server that nevertheless can have its code in this repo?

I definitely think that the Django tooling (from #61) would be a perfect candidate for extraction as an “extra”, so that folks needn’t have to install Django unless they use the Django tooling.

@markus1978
Copy link
Contributor Author

I am more worried about the dependencies than the python version. I can simply ignore the latter using --ignore-requires-python on pip install.

Having all the transformers for various platforms is great. But it makes it harder to maintain. For example, I did not found a 0.10.0 grammar and started to use my own. But I'll can never test and then pull request it, if I do not also adapt all the transformers.

@dwinston
Copy link
Contributor

@markus1978 great point about the coupling of grammar PRs to transformer tests. I had not thought of that. I am in favor of decoupling them, e.g. a given contributed transformer can be tested against given grammar versions, and there is no hard requirement for a contributed grammar to have passing tests for any transformers other than the JSONTransformer (trivial) in order to merge a PR. This is particularly valuable for pre-1.0 grammars (0.10.0 seems quite close, but it's not 1.0), as I think we should prioritize getting the 0.10.0 grammar into this repo.

Please feel free to start a WIP PR to add your 0.10.0 and reference my comment here to see if other repo maintainers agree.

@dwinston
Copy link
Contributor

It also seems that the just-merged Django transformer is pinned to the 0.9.7 grammar anyway, so you will encounter no breaking tests in adding a 0.10.0 grammar.

@markus1978
Copy link
Contributor Author

I'll agree, having transformers pinned to specific grammars will make maintenance easy enough. When I have completed the 0.10.0 grammar (+ elastic search transformer), I open PR. I'll include the necessary setup.py changes for the [server] thing.

@CasperWA
Copy link
Member

I think the [server] thing is still relevant from this issue.

@CasperWA CasperWA reopened this Nov 20, 2019
@CasperWA
Copy link
Member

I now consider this properly closed by PR #88. If new or related issues arise, please create a new GitHub issue.

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

No branches or pull requests

4 participants