RE : cctbx debian package [HEADS UP]
> Hi Radi, hi Frédéric,
Hello Baptiste
> I'm going to push my changes tomorrow, if the nightly build test runs well.
> [HEADS UP] I made important changes to the files setup.py and
> sconsutils.py. If you have any changes pending on those two files, it
> might be good to push them now, so that I can handle the merge.
maybe in that case it would be better to rebase on top of the changes currently in the git repository
git rebase origin/master is your friend.
That way we should have a linear history. I find it much convenient that way. But it is only me :)
> I made the following additions:
> * a build_py command that can add the __future__ import in the python
> files that need it
how do you decide if a package need this __future__ or not ?
I am wondering also if we miss some __future__ features.
We already have divide, what else ?
> * a clean command, that is automatically called by dh, and also cleans
> the scons build dir
yeah :)
> * a test command, that runs the tests just after build. This last part
> is still a bit buggy (see below)
> * an install_data command that knows what to do with libtbx_env (using
> Radi's modify_libtbx_env function), so that we don't need a temporary
> file any more
I do not know about this, can you explain clearly what is the problem with thoses libtbx_env files.
Maybe document this it in the wiki, so It will be easier the day we will discuss with the upstream.
> I also made the following architectural changes:
> * I moved the scons build dir inside the distutils temporary dir (I was
> unconfortable with the idea of setup.py automatically cleaning a
> directory it doesn't own)
you mean under the build directory ?
> * I moved the computation of PREFIX and BUILDDIR to be done at run time
> in sconsutils.py (cleaner, and needed for the previous point)
usually thoses variables are given to the build system by the debhelper nfrastructure.
now you tell us that we need to write the PREFIX and the BUILDDIR in sconsutils.py
before building the package ?
> I also made code changes for platform independence and consistency, and
> fixed an embarassing bug in find_packages_and_extensions which prevented
> the resulting python modules from working (inclusion of
> boost_python_meta_ext.so).
for upstream ?
> Yeah, lots of work at once, but I worked on it in complete disorder, so
> I couldn't push smaller parts.
Yes an thanks for your efforts.
Maybe we should spend some time later to reorganise the patches using
git rebase -i until we have something acceptable for the upstream, separating
debian specific patches and patch for upstream.
> The testing strategy as of now, is to test the modified python files in
. build/lib.linux-x86_64-2.6 and the just-built executables in the scons
> build dir.
Can you put your reflections about the test suite in the wiki.
I like this wiki too much :).
> Problems with the tests remain:
> * some of the tests (written either in Python or in Shell), which are
> designed to be run from the source directory, are not part of a python
> package. So they don't get installed to "build/lib.linux-x86_64-2.6".
> This leads to "No such file or directory" errors when the test routine
> tries to run them.
> * some of the tests are really very long to run (at least on my machine)
> * I don't know yet how to assess the success or failure of the tests.
> I'm afraid we might have to grep the output
> * the "setup.py test" command is not standard, therefore it doesn't get
> automatically called by dh
> For these reasons, the tests are not run yet from debian/rules.
this is not an issue in that case, a simple should do the trick
override_dh_auto_test:
# for each version of python
python setup.py test
See you
Frederic
Reply to: