-
Notifications
You must be signed in to change notification settings - Fork 27
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
Easy way to test changes? #60
Comments
Essentially what I want to try and do first is address issue #15 by taking some of the global code within For example,
Then, if this works nicely, we can go a step further and include the other types into their own directories, and then the file specific types can be in (for example) Ultimately we would then remove the spreading of everything essentially being global and small changes / type additions should be easier and |
The way I do it is like this: First setup the development environment
Now when I want to build python-flint I will do
This creates the extension module and places it in the
One point to note though is that cythonize cannot detect changes in the .pyx files (because of gh-15) so sometimes to force a rebuild you need to do:
There are no doubt ways to make this more ergonomic as a dev workflow. I haven't done that systematically because I know that python-flint needs to move to a new build system (gh-52) and if python-flint used e.g. meson then probably the way to improve all of this would be to use meson to automate things. Also personally I do absolutely everything development-wise in the terminal on unix and so this is all arranged on that basis. Probably there are other ways of doing things that others would find easier but that I just don't know about. Improvements to either the workflow scripts or to the dev docs are obviously welcome. |
That looks good to me. I think it would be good to try to do this in incremental steps so starting with pyflint.pyx seems a good idea. |
Yeah exactly, the idea was to do the smallest possible changes first to make sure that they work and I don't accidentally break anything and the ultimate goal would be a fix for issue 15. Thank you for walking me through your dev process, I really appreciate it. |
Sorry, this is a bit of a weird issue but I wasn't sure how to ask this question.
I am looking at doing some refactoring / inclusion of new types and I want to have an easy way to test to see if I am making breaking changes.
The obvious method would be to uninstall the library, then reinstall it locally and then run the tests
python -m flint.test
, but I feel as though I'm missing a trick and there's an easier way to test everything without installing the module with pip each time?Edit: for context, my hope is to break out some of the code into submodules with some additional generic classes (like
nmod_base
) to make the addition of new types in the future easier. This is also a good excuse for me to learn more about how python-flint works :)The text was updated successfully, but these errors were encountered: