refactor into a more conventional Python module file organization + distutils/setuptools setup.py

[yarikoptic]

might be of help: http://www.scotttorborg.com/python-packaging/ http://guide.python-distribute.org/

[isolver]

Definitely agree about the need for a setup.py / installer egg or something. There is another bug open for this activity already, but this issue should stay open so the suggested module / package refactoring can be looked into and considered.

If you are familiar with creating python package installers and have any time to help get this done, it would be greatly appreciated. ;)

Thanks.

Sol

On Mon, Apr 15, 2013 at 2:01 PM, Yaroslav Halchenko < notifications@github.com> wrote:

might be of help: http://www.scotttorborg.com/python-packaging/ http://guide.python-distribute.org/

— Reply to this email directly or view it on GitHubhttps://github.com/isolver/ioHub/issues/66 .

[yarikoptic]

Hi Sol,

On Mon, 15 Apr 2013, Sol Simpson wrote:

If you are familiar with creating python package installers and have any time to help get this done, it would be greatly appreciated. ;)

unfortunately not at the moment. The best I could do in available time -- is to complain and provide references ;)

Yaroslav O. Halchenko http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik

[isolver]

No prob, thought I would ask. ;)

Thanks for the references. This is something I want to do, but need to prioritize given all the current other 'to-do's'. ;)

Thanks again,

Sol

On Mon, Apr 15, 2013 at 4:36 PM, Yaroslav Halchenko < notifications@github.com> wrote:

Hi Sol,

On Mon, 15 Apr 2013, Sol Simpson wrote:

If you are familiar with creating python package installers and have any time to help get this done, it would be greatly appreciated. ;)

unfortunately not at the moment. The best I could do in available time -- is to complain and provide references ;)

Yaroslav O. Halchenko http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik

— Reply to this email directly or view it on GitHubhttps://github.com/isolver/ioHub/issues/66#issuecomment-16409819 .

[peircej]

Actually, Sol, if we move ioHub into psychopy then we don't need to generate additional installers. People would just install psychopy and then do:

from psychopy import ioHub

If you do want to keep it separate then I can certainly help you with a build script (setup.py) that supports easy_install/pip. But then I would package it /within/ psychopy lib, only as a library within the Standalone. Does that make sense?

I think I'd suggest the former solution (move it to be within psychopy) but it's your call.

[garyfeng]

I just wanted to add that our applications only use iohub, not psychopy. I wouldn't mind installing psychopy to use iohub, as we do now, but I would hope this does not affect how iohub work and its license.

[yarikoptic]

on such a note it indeed would make sense to keep ioHub as an independent module.

How psychopy would integrate it (from git submodule to just an external dependency as the others) -- is a separate question (but I hope it would not complicate my packaging of psychopy ;) )

[peircej]

On 17/04/2013 02:36, Yaroslav Halchenko wrote:

on such a note it indeed would make sense to keep ioHub as an independent module.

Sol and I have been unable to on decide this. I don't think it will make much diff either way. Licensing won't be an issue - both packages are GPL3+. Including within psychopy means it gets auto-updated when psychopy does for users of the standalone. But it's clear that it can operate independently of psychopy, so it's also quite reasonable to be an external dependency that is packaged as part of psychopy's standalone dist.

How psychopy would integrate it (from git submodule to just an external dependency as the others) -- is a separate question (but I hope it would not complicate my packaging of psychopy ;) )

Whether it's distributed as a separate dependency or as a part of psychopy the issues will be the same and (I think) minor. ioHub itself is pure python with ctypes links to various C libs (mainly eye-tracker interfaces). ioHub does add a bunch of dependencies (full list here: https://github.com/isolver/ioHub/wiki/ioHub-install) but I don't know how many are strictly required. Definitely gevent (which depends on libevent C lib) and pyaml (which ideally uses libyaml C lib). Those will end up being dependencies either of psychopy or of ioHub, but I think on linux they'll all be readily accessible from debian.

Jon

[isolver]

The wiki stuff is very out of date. The ioHub source on github includes the newer Sphinx based documentation (in progress). The installation page, for all 3 platforms, and 2.6 and 2.7 python on Windows, can be found at

ioHub/docs/iohub/installation.html#manually-installing-iohub

in the ioHub source download. That page contains the latest dependency list, which while still long, is shorter by a couple packages than before. ;)

I think ioHub integration by way of merging with psychopy makes sense in terms of reducing duplicated effort in some areas and being able to provide the best integration from a psychopy users point of view. I do not see doing this having any negative effects for anyone, using ioHub for 'psychopy windowless' event monitoring and storage will still be supported and maintained, as it is a unique feature of the ioHub framework.

However, lets get ioHub running on all 3 platforms without the list of 30-40 issues and todo's first, and then we can worry about the exact details of how to integrate ioHub with psychopy.

I think Jon would agree that this is what matters most; we both want integration in some form, but the details can be figured out once ioHub is running smoothly on all three platforms and has been verified to be working well both in terms of some outstanding long known missing functionality (like supporting various coordinate spaces, etc) and in terms of some of the late addition functional requirement, like unicode character support in keyboard events. Particularly the verification process will 'require' help and feedback from others using the framework on different keyboard layouts, locals, screen configurations, and OS's.

One thing is for sure, this is very exciting and the growing interest and support for the project is really appreciated. Every little bit counts.

Thanks!

[isolver]

restructured project (was worth doing regardless of future integration plan details); removed 80% of package self imports with relative imports.

\ setup.py is close to be done 'I think', but does not currently work.

Running pthon setup.py sdist creates a zip package with expected contents. No errors during this processes, however the zip file that is created by running python setup.py sdist does not install the package; on windows it seems like the install process just crashes.

Suggestions / ideas anyone; do not want to spend too much time on this given as Jon suggested it is likely not necessary with psychopy integration, but thought I should learn how to create one anyhow. ;)

Thanks yarikoptic for the links; they were helpful.