Packaging and Distribution

[meatballs]

The axelrod-fortran library depends upon a binary file compiled from the original fortran code. Currently, that file has to be compiled and installed on an end user's machine before this library can function. It would be preferable to provide that file as part of the distribution of the library.

Broadly, there are two options:

1. Bundle the Binary File
   We could include the binary file as part of the library. However, ctypes needs to be able to find the file for import and by default it expects to find such a file in the standard locations for the target operating system rather than locally within the Python package.

There is a method to tell cytpes where to find the binary file described in this StackOverflow question. However this StackOverflow question suggests that the solution is not thread safe.

2. Bundle the Fortran Source Code
   We could add the original fortran code to the libary and use setup.py to control the compiliation of the binary file.

If a user installs the library from a source distribution, they would need to have a fortran compiler on their own machine in order for the installation to succeed. However, we normally build and release a binary distrubtion (a wheel) using python setup.py build which would compile the fortran code into a python extension and include everything necessary within the wheel itself. Since pip's default is to use a wheel if it can find one, the end user would need to make a conscious decision to use the source distribution.

There are several methods to handle this option - most notably f2py within numpy or Cython. It's likely that they would need 'header' files to define the input and output parameters of each function more precisely, but there shouldn't be any need to modify the original fortran code in any way.

A further option to consider is exactly how to include the fortran code within this library. We could, of course, simply copy the files we want to include into the library, but that leaves us with two copies of that code. Alternatively, we could use a git submodule to include the TourExec library in its entirety such that any changes we might make are sychronised across both repositories.

[meatballs]

My gut feel is that option 2, whilst being more work to implement and get right, is the more robust solution. I propose to start some investigative work to see if I can get it up and running.

[drvinceknight]

All sounds good to me @meatballs, option 2 with a submodule seems sensible.

[marcharper]

@meatballs I'm sure it's been a while since you'd thought about this. With PR #77 merged this may be easier since we can now load the dll from any static location.

[meatballs]

Yep - I thought that too, but haven't had time to look into it again.