search

Chemellia / ChemistryFeaturization.jl

Interface package for featurizing atomic structures
https://chemistryfeaturization.chemellia.org/dev/
MIT License
41 stars 14 forks source link

PyCall may be a CI hurdle #108

Open DhairyaLGandhi opened 3 years ago

DhairyaLGandhi commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.