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

Easy way to test changes? #60

Closed
GiacomoPope opened this issue Aug 17, 2023 · 4 comments
Closed

Easy way to test changes? #60

GiacomoPope opened this issue Aug 17, 2023 · 4 comments

Comments

@GiacomoPope
Copy link
Contributor

GiacomoPope commented Aug 17, 2023

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

@GiacomoPope
Copy link
Contributor Author

Essentially what I want to try and do first is address issue #15 by taking some of the global code within pyflint.pyx to clean up

For example, pyflint.pyx contains these base classes such as flint_elem. The idea would be something like:

flint/
├─ flint_base/
│  ├─ flint_types.pxd
│  ├─ flint_elem.pxd
│  ├─ flint_elem.pyx
│  ├─ flint_scalar.pxd
│  ├─ flint_scalar.pyx
│  ├─ flint_poly.pxd
│  ├─ flint_poly.pyx
│  ├─ ...
├─ _flint.pxd
├─ pyflint.pxd
├─ pyflint.pyx
├─ ...

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) nmod_poly.pxd, etc.

Ultimately we would then remove the spreading of everything essentially being global and small changes / type additions should be easier and pyflint.pyx would have from XXX cimport * instead of the various includes.

@oscarbenjamin
Copy link
Collaborator

The way I do it is like this:

First setup the development environment

source bin/activate  # sets environment variables for .local
bin/build_dependencies_unix.sh # builds flint etc in .local

Now when I want to build python-flint I will do

bin/build_inplace.sh

This creates the extension module and places it in the src/flint directory so that it is importable along with the surrounding Python code. To be able to use it though you need to add the .local env vars:

source bin/activate
python -m flint.test

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:

rm src/flint/ptflint.c
bin/build_inplace.sh

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.

@oscarbenjamin
Copy link
Collaborator

For example, pyflint.pyx contains these base classes such as flint_elem. The idea would be something like:

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.

@GiacomoPope
Copy link
Contributor Author

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.

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