-
Notifications
You must be signed in to change notification settings - Fork 14
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
PyCall may be a CI hurdle #108
Comments
To respond to your title: yes, no question! To respond to your comments, in order:
|
Well, I can appreciate the thoughts going into such a decision - it's potentially an increase in development overhead too. Re 3 - I was thinking of a sort of meta API that lives here, and a secondary package that does just io. Sort of how FileIO exists but then you have ImageIO ImageMagick etc etc underneath which can have varying degrees of complexity. So this would still be the package that users download, but it's easier for other people to add io backends (assuming there's more of these formats (don't forget to count .jls, .hdf5, .jld, .bson if we want support for these at all) than can be reasonably assembled, developed and maintained in one place). Totally not something that needs to happen, but thought I'd share why I brought it up :) |
Yeah I do like the idea of multiple backends, so someone could just use Xtals.jl if that gives them all the functionality they need, but opt to do the Python-based one if they need to read some other kind of file format...I'll probably have to take some time to think about what exactly that should look like, though... |
Let me know what kind of artifact-ing you're looking into and I'd be happy to help with that too, if its useful. |
Currently it's only used for graph IO/ building with
ase
andpymatgen
. Would it be hard to have Julia versions of these? Are there artifacts that we can use instead? Maybe consider spinning the PyCall dep to a separate package?The text was updated successfully, but these errors were encountered: