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

--py-solve doesn't actually generate the Python interface #6

Open
scopatz opened this issue Sep 11, 2017 · 10 comments
Open

--py-solve doesn't actually generate the Python interface #6

scopatz opened this issue Sep 11, 2017 · 10 comments

Comments

@scopatz
Copy link
Member

scopatz commented Sep 11, 2017

I am working on pyne integration (in the pyne/src dir) and running the command:

$ python -m transmutagen.gensolve --py-solve --namespace=pyne_cram --outfile=cram.c

and I am only seeing the cram.c and cram.h file generated...

@scopatz
Copy link
Member Author

scopatz commented Sep 11, 2017

Oh, I guess that pysolve isn't generated at all...

@scopatz
Copy link
Member Author

scopatz commented Sep 11, 2017

Which makes the gensolve docs misleading:

--py-solve            Generate code for py_solve.

@asmeurer
Copy link
Member

It should probably be clearer. py_solve isn't a generated module. It's a hard-coded test module that lives alongside transmutagen. python -m transmutagen.gensolve --py-solve generates the generated code of py_solve (py_solve.c and py_solve.h).

If you need generated Cython code that isn't implemented yet. For pyne, I would just copy py_solve.pyx and modify it for pyne's needs, then generate the appropriate C file with transmutagen.gensolve

@scopatz
Copy link
Member Author

scopatz commented Sep 11, 2017

Yeah, I am doing something like that for pyne. I think that this is effectively a docs issue at this point.

@asmeurer
Copy link
Member

We don't have much docs yet (just the README, docstrings, and command line help). We should build some Sphinx docs at some point. How high priority do you think it is?

@scopatz
Copy link
Member Author

scopatz commented Sep 11, 2017

I would put it at a moderate priority, only if we wanted to push a paper out through JOSS

@scopatz
Copy link
Member Author

scopatz commented Sep 11, 2017

We should think about if we want to do that before or after the full paper

@asmeurer
Copy link
Member

The only question is if having one published affects the publishing of the other (either positively or negatively). I thought I remembered Lorena saying that software that will have full blown papers shouldn't submit to JOSS (but I could be wrong).

JOSS would be easier. We just need better documentation for it (unless there's something else they require that I'm forgetting about).

@scopatz
Copy link
Member Author

scopatz commented Sep 11, 2017

I think that having a JOSS paper could slightly positively affect the full paper by having a DOI that we can cite to the software that isn't just a figshare or some such. However, I don't want to delay the full paper in any way. It seems like we can add a citation during review / edits if we want.

@scopatz
Copy link
Member Author

scopatz commented Sep 11, 2017

In other word, we can do the JOSS paper later

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