Better packaging

[peircej]

The packaging of labjackpython could be much improved by:

1. providing a wheel so that people can just pip install labjack
2. putting all the files in one folder

Doing 1. doesn't have any downsides and would help people have access to your current work (at the moment they have to navigate to github to find the latest version rather than doing pip install labjack). It's possible the wheel(s) could include the driver too unless that needs to alter OS

Doing 2. has the slight downside that people should import by doing from labjack import u3 rather than import u3. So it would break code very minimally, but the current way that labjack gets installed is pretty bad; it's like installing an application by just dumping all the files in the root of "Program Files" rather than in a folder for that app

[background: I'm the creator of the PsychoPy package and we have lots of labjack users, but it's annoying for me supporting dependent hardware/libs when they each have a different install method]

[peircej]

I meant to say I'd be happy to implement either of the above if you could use the help

[mnaberez]

providing a wheel so that people can just pip install labjack

The reason that pip doesn't install LabJackPython is because the package doesn't have a PEP 440 compliant version string. While I think packaging it as a universal wheel is a good idea, changing the version from 4-24-2014 to something compatible with PEP 440 like 1.0 should allow it to be installed without other packaging changes.

A workaround is to specify a specific version requirement to pip:

$ pip --version
pip 8.1.2 from /path/to/lib/python2.7/site-packages (python 2.7)

$ pip install LabJackPython
Collecting LabJackPython
  Could not find a version that satisfies the requirement LabJackPython (from versions: 4-24-2014, 9-20-2010)
No matching distribution found for LabJackPython

$ pip install LabJackPython==4-24-2014
Collecting LabJackPython==4-24-2014
  Downloading LabJackPython-4-24-2014.zip (113kB)
    100% |████████████████████████████████| 122kB 2.3MB/s 
Building wheels for collected packages: LabJackPython
  Running setup.py bdist_wheel for LabJackPython ... done
  Stored in directory: /path/to/pip/wheels/85/68/1a/058bda104b9f9eb8b2984ebd1c20a9bbb50017c379d6c23a24
Successfully built LabJackPython
Installing collected packages: LabJackPython
Successfully installed LabJackPython-4-24-2014

[davelopez01]

1. I've been considering changing the LabJackPython versioning to be PEP 440 compliant. Our next official release will likely stop using the date string for the version and change to a major.minor type format starting at 2.0. We will add a package for this on PyPI so it can be found/installed properly through pip.

Regarding a wheel, I haven't used those and would need to look further into it. At minimum we can add a wheel with only the Python modules. Not sure with the drivers though. May need to keep the requirement of running the appropriate OS installer beforehand for the device drivers, then run the pip command for Python side installation.

2. I've also considered making a labjack directory/package for LabJackPython for the 2.0 release for better organization. With the newer LJM Python interface we do this.

I'm not exactly sure though when version 2.0 will be released. I plan on it including the Python 3 support (still WIP) and the full removal of skymote code. I haven't had much time to work on it lately since we (LabJack) have been focusing on a new DAQ product.

[peircej]

Thanks for the info. Glad to hear these things (and py3 support) are all in the pipeline :-)

If your driver installer is just placing a dll/dylib somewhere, which is being accessed by python/ctypes, then you can certainly just include the dll/dylib in the wheel with the python library. Really easy to do that - see an example here: http://stackoverflow.com/questions/24071491/how-can-i-make-a-python-wheel-from-an-existing-native-library

You end up pushing to pypi one wheel for each distribution, which is a bit more annoying for you but advantages:

• you know that the user isn't accidentally using a broken version of the driver
• you know exactly where it is - the user hasn't moved it or put it in the wrong location

If the installer currently is doing additional things (e.g. registry hooks or path settings) then it will still be needed because pip install can't run post-install scripts.

Let me know if you'd like any help with it - I can provide pull requests to help things along if needed. :-)

[davelopez01]

Thanks for providing this information. It doesn't sound like we can do a proper installation of our libraries (dll/dylib/so) with a wheel if it can only copy files. We need post-install script capabilities on Linux and Windows. Possibly on Mac too.

[machnic]

Is there any follow-up on adding the package to pypi? There is already some version of LabJackPython but it's not the latest one (even though the version suggests it).

[davelopez01]

That version on PyPI is the last "stable" release 5-26-2015 which only supported Python 2.5, 2.6 and 2.7. The versioning was changed to 1.201505 (1.yearmonth) so PyPi would accept it.

The current code in this repository is in a beta state for Python 3 support. There hasn't been a stable release for GitHub and PyPI since 2015. There is no timeframe when we will continue development and testing for Python 3 again, but we do plan on it at some point.

[machnic]

Thank you for the feedback. I hope you'll find time to continue development and testing for Python 3 (rather sooner then later).

[badboybeyer]

I have been publishing the module to pypi.org as sti-LabJackPython.

https://github.com/badboybeyer/sti-LabJackPython

https://pypi.org/project/sti-LabJackPython/

[machnic]

@davelopez01 Is it be possible for you to push the latest version to pypi? I understand that not whole functionality was tested for Python 3 but having the support here in the repository and not pushing it to pypi only makes life harder when it comes to managing dependencies :/

[davelopez01]

Thanks for the nudge @machnic . As of today I updated LabJackPython to 2.0.0 with what we currently have in the GitHub repo. for an official release, and put it on PyPi:

https://pypi.org/project/LabJackPython/

I mentioned in an earlier post considering moving to a labjack directory/package for the 2.0 release. I didn't end up doing that for backwards compatibility.

[machnic]

Thank you @davelopez01. This will already simplify a lot working with LabJack using Python 3.

Moving to a labjack directory/package still would be a nice feature though.

It could be done even taking backward compatibility concerns into account. For the time being, the directory/package could simply coexist with the current modules (let's say until version 3.0.0), and imports in the current form could give a DeprecationWarning. If you make sure that people actively using the library have enough time to make a transition, it shouldn't be much of an issue. For all the others, even if the possibility to import in the current form would be completely dropped, issues with the currently implemented code could be easily solved by limiting maximum version of LabJackPython to <x.x.x in the requirements.