linux swmm5.so no included in pypi package

[lrntct]

When installing pyswmm with pip, pyswmm/lib/linux/swmm5.so is not included, resulting in an OSError "cannot open shared object file: No such file or directory".

[bemcdonnell]

@lrntct, this should be addressed very soon:

#132

We are in the process of migrating to building swmm as a python extension. Pretty soon we will no longer need to provide prebuilt binaries inside of the repo

[bemcdonnell]

The project will soon fully support all platforms and architectures. USEPA swmm has been exclusively built on windows with visual studio 32bit. Once we finish the regression testing, this project will formally endorse support on other platforms. We’re very very close!!!

[lrntct]

I missed #132, sorry.
Those are very good news! I just spent some hours trying to build swmm as a python extension, and it is only partially working:
https://travis-ci.org/lrntct/pyswmm/builds/310743125

[bemcdonnell]

@lrntct, We have an issue here on the SWMM repo for Adding SWIG support to SWMM.
pyswmm/Stormwater-Management-Model#71

Would you like to share some of your experience over there?

[bemcdonnell]

We are going to keep the interface files inside that repo. I believe our plan is to use pip to fetch the "release" from OWA/SWMM github page, and build with SWIG.

[bemcdonnell]

@lrntct, actually, based on what I am seeing - the work you are doing will be a much cleaner implementation than #132 since your work is going to build swmm. If you want to continue it and submit it in a PR, I think it will be a nice addition

[lrntct]

If I understand well, this SWIG interface will by part of OWA-SWMM and swmm will then be packaged and distributed by pypi and/or anaconda? Then pyswmm will depends on it? Is that the objective?

If that so, my current work might be redundant quickly.

[bemcdonnell]

@lrntct, @michaeltryby has done quite a bit with SWIG. The interface file will live with OWA-swmm but as far as I can tell, it will not be packaged independently from pyswmm. To be honest, there is a difficult line between the two repositories. Swmm we’d like it to be python agnostic as much as possible. Do you have any suggestions with the approach? We want to keep these projects simple and separate so that developers in C need not be required to learn python.

As far as I know, you can Build a python extension with SWIG with and already compiled library. If we go this route, the extension swmm.pyd would simply wrap swmm.dll.

[bemcdonnell]

So to answer your question; you have a great point that those contributors could be deprecated quickly.

[lrntct]

To be honest, there is a difficult line between the two repositories. Swmm we’d like it to be python agnostic as much as possible. Do you have any suggestions with the approach? We want to keep these projects simple and separate so that developers in C need not be required to learn python.

It might be possible to create a directory in the SWMM repo with just the necessary files to create a python package (setup.py etc.). Having a separate python package for SWMM only, with pyswmm depending on it, might be the easiest and most separate way to go. This would add minimal python code to the swmm repo.
However, I never created a pure C python package, I don't know how it would look like.

On the other hand, if you manage the build aand packaging inside the pyswmm repo, you'll need to import the swmm source code at some point, either by wget or git clone, or by adding swmm as a git submodule in the pyswmm repo. The latter is what I did in the code I posted earlier.

As far as I know, you can Build a python extension with SWIG with and already compiled library. If we go this route, the extension swmm.pyd would simply wrap swmm.dll.

If the new solution still consists in importing a binary blob inside the pyswmm repo, I don't see much benefit compared to the current situation.