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

PyCall may be a CI hurdle #108

Open
DhairyaLGandhi opened this issue Jul 21, 2021 · 4 comments
Open

PyCall may be a CI hurdle #108

DhairyaLGandhi opened this issue Jul 21, 2021 · 4 comments

Comments

@DhairyaLGandhi
Copy link
Member

Currently it's only used for graph IO/ building with ase and pymatgen. 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?

@rkurchin
Copy link
Member

rkurchin commented Jul 21, 2021

To respond to your title: yes, no question!

To respond to your comments, in order:

  1. Yes, that's a big part of what the BoF session is going to be about ;) That being said, there are Julia packages that offer some of that functionality (notably, Xtals.jl for things like .cif and .xyz files), so I'm considering switching to depend on those, though it would strictly be a drop in overall functionality. The only thing I really need pymatgen for is the Voronoi decomposition stuff, which may exist in another Julia package; I just haven't looked into it.
  2. I've been thinking about looking into making artifacts, but haven't taken the plunge yet as I suspect getting it all to work would be a lot of effort.
  3. I don't think that necessarily makes sense; this is the package that's suppose to do the IO and graph-building...

@DhairyaLGandhi
Copy link
Member Author

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 :)

@rkurchin
Copy link
Member

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...

@DhairyaLGandhi
Copy link
Member Author

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.

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

2 participants