Supporting conda installs

[peircej]

It sounds like people are keen to have conda install methods for better dependency support than pip (although I don't use it and don't know in what way the dependency support is better)

I guess Erik's conda package is out of date. Do we update that or start again?

Do instructions need updating?

[hoechenberger]

A conda package would be very much appreciated.

In the meantime, we could:

• provide environment files for all supported platforms
• along with updated installation instructions

I would be willing to look into this / help looking into this.

[stfnrpplngr]

The approach of @hoechenberger works with minor changes as described in Issue #1813.

[kastman]

This has been at the top of my list for a while, and is absolutely worthwhile; feel free to assign it to me.

I've just taken a first pass at this, and it's amazing how much easier it is with a mature conda-forge compared to that hackathon at Nottingham! Looking back it really feels quite gauche, even.

I've filled in the easy packages in a new PR for conda, but there are a few packages that take special care.

1. Pygame - SDL2 is available in conda-forge, but SDL is not. Just double-checking that psychopy really uses SDL. I may have to add it to conda-forge if that's the case.

2. python-bidi - Some packaging trouble on the local CI so I submitted it as a separate PR, but it seems that remote didn't have a problem with it.

Happy to see the dependency on pysoundcard has gone away. I had started it on conda last year but failed on the portaudio dependency.

I'm glad to know that @hoechenberger 's environment.yaml solution works, but I'm happy to put in the effort to get things as smooth as possible all conda.

[hoechenberger]

@kastman Wow that's neat! Yes, conda-forge makes life so much easier :=) Will try your package next week (after my vacation :))

[peircej]

I'm very comfortable with pygame support being dropped if it makes things easier. the only thing that pygame has done better than pyglet (in a long time) is supporting joysticks. We've got a new backend using glfw that supports joysticks and might supercede both pygame and pyglet.

pysoundcard has gone, but sounddevice is a new alternative and is rather similar in its dependency on portaudio. Is that a problem for conda?

[peircej]

Ah, apparently sounddevice is on conda forge so hopefully that's easier https://github.com/conda-forge/python-sounddevice-feedstock

[kastman]

Yep - got sounddevice already (but I'm still not sure how the ygot aorund the portaudio CI issue).

Pygame is troublesome (it does use SDL and not SDL2, right?) So removing support would certainly be an option.

Currently outstanding are a version bump to pyglet and a question about version locking on the conda-forge PR.

[hoechenberger]

@kastman @peircej I've created a fresh fork of conda-forge/staged-recipes at https://github.com/psychopy-conda/staged-recipes; and I've added a basic PsychoPy recipe to the psychopy branch.

It does build successfully on my Mac; haven't tested on Windows and Linux so far. (Do you guys, by any chance, have a Windows 10 box available?)

Currently missing dependencies:

• pyparallel
• pygame
• psychHID

The first two I would simply ignore; the last one we should try to compile & add at one point, but to get started initially, I don't think it's necessary to have it if it makes packaging difficult. Just trying to push out a basic PsychoPy package for now that will work for a majority of users.

The psychopy-conda organization I created is just supposed to exist temporarily until we finish working on the recipe.

[hoechenberger]

I've opened a new PR at https://github.com/conda-forge/staged-recipes/pull/8645 to take advantage of the conda-forge CI services.

[hoechenberger]

@kastman Since we currently have neither a pygame nor a pysoundfile build for Windows on conda-forge, we can't ship with sound support on that platform :\ However we can of course let users know how to install those dependencies via pip afterwards, or provide an environment file for convenience. I've temporarily disabled import tests for psychopy.sound on Windows.

[hoechenberger]

Update: So this is now building successfully on macOS and Windows (albeit without sound support on the latter); I'm still struggling a little with Linux, where it does complete the build step, but some tests don't pass (OpenGL issues related to the headless host system, not to PsychoPy / the package itself).

[hoechenberger]

It's done:

$ conda create -c conda-forge --name psychopy-study psychopy
$ conda activate psychopy-study
$ psychopy

Please note that we currently do not have any sound libraries packaged for Windows.

[hoechenberger]

@kastman The next step would be to package libsndfile for Windows, I guess? And psychHID for all platforms.

[hoechenberger]

Todo:

• [ ] psychHID conda package
  • [ ] Depends on libusb, package that first!
• [x] pyGLFW conda package
  • [x] requires glfw build for macOS
• [ ] sound support on Windows
  • [ ] requires libsndfile build for Windows; see stalled attempt
• [ ] maybe start another attempt to get pyparallel onto conda-forge
• [ ] add menu entries via menuinst
• [ ] build installer via contructor

[kastman]

@hoechenberger I think I can finally make up the patch for libsndfile since we know it will finally be used (I think you're also looking for https://github.com/conda-forge/libsndfile-feedstock/pull/7 too).

Do we still need to add psychHID as well? And will menuinst and constructor "prettify" the app like Jon's normal build?

PS - I also really appreciate the comment from glfw :"well, we aren't opposed to it." You really make things easy on yourself...

[hoechenberger]

@kastman

@hoechenberger I think I can finally make up the patch for libsndfile since we know it will finally be used (I think you're also looking for conda-forge/libsndfile-feedstock#7 too).

I've added the link to this PR to the todo list :)

Do we still need to add psychHID as well?

Right, I totally forgot about this! In fact, this should be of high priority! I'v added it to the list.

And will menuinst and constructor "prettify" the app like Jon's normal build?

Yes, I believe this is what it can do!! Don't know how usable the constructor is (maybe pyInstaller etc. are better); but menuinst is defintely worth a shot, this can be used to create menu entries even without a standalone installer (just by installing the condapackage)

PS - I also really appreciate the comment from glfw :"well, we aren't opposed to it." You really make things easy on yourself...

Haha, yes :) Thinking back of our struggles with pyparallel... Damn. I propose we start another attempt with pyparallel and skip Windows from the beginning. Maybe it will get through the review process this time :)

[peircej]

For info on python-psychtoolbox (psychHID) under Mac:

As it happens that just stopped building for me (again) so I was digging around. The error was the same as I'd had once before about carbon header not being found (pasted below).

That can be fixed by doing this:

xcode-select --install

then

/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

as explained here https://stackoverflow.com/questions/52509602/cant-compile-c-program-on-a-mac-after-upgrade-to-mojave/52530212#52530212

After that step a simple python setup.py bdist_wheel from the root of psychtoolbox git repository worked for me to build a wheel.

I'm making some tweaks to the psychtoolbox code at the moment, to improve the pythonic wrapper to the ugly matlab-style code :wink:

Jon

carbon header error:

building 'GetSecs' extension
/usr/bin/clang -fno-strict-aliasing -Wsign-compare -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -arch i386 -arch x86_64 -g -DPTBMODULE_GetSecs -DPTBMODULENAME=GetSecs -DPTBOCTAVE3MEX -DPSYCH_LANGUAGE=PSYCH_PYTHON -IPsychSourceGL/Source/Common/GetSecs -I/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/numpy/core/include -IPsychSourceGL/Source/Common/Base -IPsychSourceGL/Source/Common/Screen -IPsychSourceGL/Source/OSX/Base -IPsychSourceGL/Source/OSX/GetSecs -I/Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m -c ./PsychSourceGL/Source/Common/Base/PsychInit.c -o build/temp.macosx-10.6-intel-3.6/./PsychSourceGL/Source/Common/Base/PsychInit.o -Wno-date-time -mmacosx-version-min=10.9
In file included from ./PsychSourceGL/Source/Common/Base/PsychInit.c:31:
In file included from PsychSourceGL/Source/Common/Base/Psych.h:23:
In file included from PsychSourceGL/Source/Common/Base/PsychConstants.h:54:
In file included from PsychSourceGL/Source/Common/Base/PsychIncludes.h:128:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:34:10: fatal error: 
      'CarbonSound/CarbonSound.h' file not found
#include <CarbonSound/CarbonSound.h>
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
error: command '/usr/bin/clang' failed with exit status 1

[peircej]

This could do with looking at again, one day, as various things have changed:

• A number of dependencies do now exist as wheels (e.g. psychtoolbox on all platforms) and others may have been added to conda (e.g. soundfile?)
• I'm currently also working on a system for providing fewer core dependencies and adding others as extras to be installed with pip install psychopy[hardware] or possibly entire separate packages like pip install psychopy-hardware. See discussion of that at https://discourse.psychopy.org/t/yet-another-topic-on-installation-dependencies/28414/17