| Reference | Downloads | Github

Build a dev-only release

Given the particularly huge set of changes in the next major PsychoPy release (including the massive code refactor for Python3) I’d like to release a developer “pre-release” called 1.90.dev1 preceding the usual 1.90.0

There’s a post (from 2011) saying we shouldn’t release anything but stable versions on PyPI because the tools can’t discriminate

But then the documentation for pip indicates that the flag --pre overrides pip’s default behaviour of only installing stable releases. So, if that documentation is correct, I could release 1.90.dev1 and it won’t be installed with pip install psychopy but will be installed with

pip install psychopy --pre

What are people’s thoughts?

I’m in favor of a developer release, because I will definitely need to test out a bunch of things on an upgrade like this. Is there any downside to releasing it with the --pre flag?

I think the problem is that easy_install doesn’t prioritise stable versions in the way that pip claims to do, so if anyone is still using easy_install they’ll accidentally get a developer release. But that’s why I think this was more of a problem in 2011.

I should say as well, though, that you can do an install from the repository to test it as well.

I think a development release is a good idea - it signals that things are ready to test and provides a common reference point.

OK, I’ve published a “dev” release, version 1.90.dev1 as a prelude to 1.90.0

I’ve uploaded Standalone Win/MacOS versions in both Python2.7 and Python3.6 to

You can also now install to any python installation using pip install psychopy and this will install nearly all the dependencies (except that pyo is still not available that way).

So to get a dev version running on python3, separate from your main standalone installation you can just install Python3 and do pip3 install psychopy

The easiest way to launch the app is

python3 -m

OK, there don’t seem to have been many issues with the release (a couple of problems around packaging that I think I’ve fixed). I think I’m ready to release 1.90.0 but let me know ASAP if you’re working on something that you’d like to finish before the release.

Things I know about:

  • @mdc the work on glfw looks worth including so that people can give it a test run, but we won’t direct people to use it right now
  • @djmannion let me know when your changes to gamma are ready to ship
  • @hsogo12600 did you have anything else you wanted, after the pyo backend adjustments?

Is going to be a huge and exciting release! It will be so good to get this one done and out the door!

I noticed that Builder experiments created in older version doesn’t work in 1.90 if MouseComponent is included. Typical error message is following:

  File "C:\Users\Hiroyuki\Desktop\", line 276
    if not continueRoutine:  # a component has requested a forced-end of Routine
IndentationError: expected an indented block

This error seems to occur because value of forceEndRoutineOnPres is True or False in old MouseComponent, which cannot be recognized by new
MouseComponent. It would be difficult to guess what’s wrong from this error message. I think new mouse component should translate True / False to new values.

Thanks @hsogo12600
I thought I’d fixed that already but it turns out that I hadn’t done it quite right! The fix is being pulled at the moment:

I’m going to add some documentation to the GLFW backend about the additional arguments that can be passed to its constructor. Should be up shortly.

P.S. And it’s up.

The packaging is working great in linux; a pip install is all that is needed to get a pretty much empty virtualenv ready to go!

I’ll update the pull request with the feedback and do some testing. Hopefully within a couple of days.

Some strings in Builder dialogs are not translated. I’ll add translation asap.