[Reproducible-commits] [blog] 01/01: First draft of week 5, about setuptools and autopkgtest

[Ceridwen]

This is an automated email from the git hooks/post-receive script.

ceridwen-guest pushed a commit to branch master
in repository blog.

commit 1c6adc2584919e524b51ee26d5ca65a548a1a237
Author: Ceridwen <ceridwenv at gmail.com>
Date:   Fri Jun 24 18:50:52 2016 -0400

    First draft of week 5, about setuptools and autopkgtest
---
 drafts/people/ceridwen/reprotest_week5.mdwn | 48 +++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/drafts/people/ceridwen/reprotest_week5.mdwn b/drafts/people/ceridwen/reprotest_week5.mdwn
new file mode 100644
index 0000000..f48eec5
--- /dev/null
+++ b/drafts/people/ceridwen/reprotest_week5.mdwn
@@ -0,0 +1,48 @@
+[[!meta title="Reorganizing the autopkgtest code"]]
+[[!meta date="Mon, 20 Jun 2016 14:30:02 -0400"]]
+[[!tag reproducible_builds Debian reprotest Outreachy]]
+Author: ceridwen
+
+If the authors of autopkgtest had *deliberately* chosen a structure
+designed not to work with setuptools, I don't know if they could have
+done a better job.  As I discussed [last
+week](https://reproducible.alioth.debian.org/blog/posts/people/ceridwen/reprotest_week4/),
+autopkgtest has Python scripts in `virt/` that are executed by
+`subprocess` calls in `adt_testbed`.  Because these scripts import
+files from `lib/`, there needs to be an `__init__.py` in `virt/` to
+make it into a package and a `sys.path` hack in each script to allow
+it to find modules in `lib/`.  Unfortunately, setuptools *will not
+install* this structure.  First, setuptools will not install any file
+without a `.py` extension into a package.  Theoretically, thisis
+fixable, they are Python scripts so I could rename them.
+(Theoretically, there's supposed to be some workaround involving
+`MANIFEST.in` or `package_data` in `setup.py`, but I have yet to find
+any documentation or explanation giving a method for installing
+non-Python files inside a Python package.)  Second, however,
+setuptools does not preserve the executable bit when installing
+package files.  The obvious workaround, changing the `subprocess`
+calls so that they invoke `python virt/foo.py` rather than
+`virt/foo.py` requires changing all the internal calls in the
+autopkgtest code, which I'm loathe to do for fear of breaking it.
+(It's not clear to me I can easily find all of the calls, for
+starters.)
+
+There are about three solutions to this I see at the moment, all of
+them difficult.  The first involves using either the `scripts` keyword
+or `console_scripts` entry point in `setup.py`, as explained
+[here](http://python-packaging.readthedocs.io/en/latest/command-line-scripts.html).
+The `scripts` keyword is supposed to preserve the executable bit
+according to [this StackExchange
+question](https://stackoverflow.com/questions/7007985/how-do-i-make-setuptools-set-the-executable-bit-when-deploying-some-supporting-b),
+but I haven't verified this myself, and like everything to do with
+setuptools I don't trust anything anyone says about it without testing
+it myself.  It also has the disadvantage of dumping them all into the
+common scripts directory.  Using `console_scripts` involves rewriting
+all of them to have an executable function I can refer to in
+`setup.py`.  I worry that this would be both fragile and break
+existing expectations in the rest of the autopkgtest code, but it
+might be the best solution.  The third solution involves refactoring
+of all the autopkgtest code to import the code in the scripts rather
+than running it through `subprocess` calls.  I'm reluctant to do this
+because I think it's almost certain to break things that will require
+significant work to fix.

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/blog.git