search

pchanial / pyoperators

Operators and solvers for high-performance computing.
http://pchanial.github.com/pyoperators
Other
14 stars 9 forks source link

Packaging for Debian #12

Closed ghisvail closed 9 years ago

ghisvail commented 10 years ago

HI Pierre,

I intended to package pyoperators for Debian (make it apt-get able) but figured I should ask you first if you were interested. There is not much to do on your part and your module looks well tested and designed, so packaging should be straightforward.

Please let me know if you have any objection to it.

Ghis

pchanial commented 10 years ago

Hi Ghis, that's great, go ahead ! 0.12.13 is very stable. Let me know if you have any trouble or if I can help.

ghisvail commented 10 years ago

I had a go at it and it looks good. Some minor remarks,

Cheers, Ghis

pchanial commented 10 years ago

Great! 1) the source of the documentation is in the github branch gh-pages. It's in textile markup, so I wonder if it would be of any help to include it in the source. I could copy over the static pages though, I'll think about it. There's a proceeding on PyOperator too that I could include, also. 2) do you have an example to do that ? 3) the copyrights should be updated, I'll try to do that this week, but It will most likely done beginning of next week. 4) no, not for PyOperators 5) so far, nobody asked for a Python 3 compatible version. I'd be happy to provide that when someone needs it. and out of curiosity, for what project are you using PyOperators?

ghisvail commented 10 years ago

1) The lack of documentation is not a massive issue since users who ask for it may just be redirected to the gh-page. 2) http://docs.cython.org/src/reference/compilation.html, section "Distributing Cython modules" 3) you don't need to update the files just for that though, just confirm that the dates and names of the copyright I gave you are correct 4) good 5) Well I am actually transitioning my whole stack towards Py3, since Spyder has been updated to support it. For your case, it might be just a question of calling 2to3 to correct any non compliant Python code. That's something I could help you with easily.

I now use pyoperators for my MRI reconstruction toolbox. I have maintained my own operator-like library, called linop and available on my github, but it is still fairly rudimentary compared to what you provide. I believe the 2 can co-live since mine only provides an interface for forward, adjoint and composition of operators, whilst your library allows for deeper control of the properties of the operators, their memory footprint...

Regarding the package, it was painless to make. I'll file an upload request soon.

pchanial commented 10 years ago

I have come up with a new version (0.12.14) that should address your concerns (except Python 3). It also fixes the few tests that I forgot to update.

1) I have added the documentation link to the README.rst file. 2) done: to activate the cythonization, set the following in setup.py : 

 hooks.RECOMPILE_CYTHON = True

3) The copyrights should be Pierre Chanial 2010-2014 and Nicolas Barbey 2010-2012 5) I am willing to make PyOperators compatible with Python 3. Since you're transitioning your stack, you'll be quite experienced on it and I would appreciate your help. I don't know how much of that could be hidden in the hooks.py file I'm using.

That's nice. If you've coded some Operators that are of general interest, it might interesting to include them in the codebase. Have you had a look to another package I am maintaining : PySimulators? It eases the steps of building an acquisition model (i.e. scene + instrument + sampling + noise model) and provides other operators. The documentation is seriously behind but I am working on it right now for the next 1.1 release.

ghisvail commented 10 years ago

Good. I'll have a look at the new version.

For Python 3 support, it could as easy as calling 2to3 at build time if your code does not deviate from the compatibility layer which exists between Python 2.7 and 3.x.

Then another question is also how much you need to support past versions of 2.x, like 2.5 or 2.6. If you don't care too much, then a first step would be to make pyoperators fully 2.7 compliant (and drop deprecated 2.x stuff) and see what 2to3 says.

I'll check out pysimulators. If you deem it worthy of packaging as it stands, I could also give it a shot.

pchanial commented 10 years ago

Thanks, I'll have a try next week for the Python 3 conversion. For PySimulators, I need to clean up quite a lot of redundant code. But that's a good incentive to finalize it. I'll keep you updated.

ghisvail commented 10 years ago

There is a slight issue with the cythonize command that I'd like to discuss. I'll open a separate issue for it.

I'll open a separate issue for the Python 3 support as well.

I'll close this issue once I get the confirmation that the package is ready for upload.

pchanial commented 9 years ago

Hi Ghislain. I have tagged the latest commit as 0.12.15, which fixes all the issues that we discussed. I think it is ready for upload, thanks a lot!

ghisvail commented 9 years ago

The clean command is not sufficient and would probably crash if git is not installed.

I am filing a specific issue for i, where we can discuss it.

ghisvail commented 9 years ago

Also a little off-topic here, but I wanted to ask whether you had something specific planned for v0.13 ? With the projects I have worked with, a support for Python 3 usually translated in a major version bump, "pour marquer le pas".

It's really just out of curiosity, I wouldn't particularly mind whether the released version after the fixed clean command version would translate to 0.12.16 or 0.13.

pchanial commented 9 years ago

You're right, I should make it 0.13... but I won't have time to rebase 0.12 to master before Monday.

2014-10-10 12:00 GMT+02:00 ghisvail notifications@github.com:

Also a little off-topic here, but I wanted to ask whether you had something specific planned for v0.13 ? With the projects I have worked with, a support for Python 3 usually translated in a major version bump, "pour marquer le pas".

It's really just out of curiosity, I wouldn't particularly mind whether the released version after the fixed clean command version would translate to 0.12.16 or 0.13.

— Reply to this email directly or view it on GitHub https://github.com/pchanial/pyoperators/issues/12#issuecomment-58635780.

pchanial commented 9 years ago

I have cherry-picked on master all the commits in v0.12 that weren't included, and I just tagged the 'clean command' commit as 0.13. If you're ok with it, it can be the version for the debian package.

pchanial commented 9 years ago

Sorry about that: I forgot to cleanup the history from v0.12 before pushing it. So I did it and forced a rebase (bad!). In case you pulled it, you'll have to either pull the branch v0.13 or on master:

$ git reset --hard 86bc868
$ git pull
ghisvail commented 9 years ago

Submitted:

bugs.debian.org/cgi-bin/bugreport.cgi?bug=765561

I will close the bug once the package is accepted in the upload queue.

ghisvail commented 9 years ago

Done.

http://lists.alioth.debian.org/pipermail/debian-science-maintainers/2014-October/028087.html

pchanial commented 9 years ago

That was fast, good job! I've seen that you've included pyfftw, that's great!

ghisvail commented 9 years ago

Yes, I worked with Henry to get it packaged too. It is a suggested package when installing the python*-pyoperators package.