| Reference | Downloads | Github

Why isn't PsychoJS in its own repository?


Considering they are effectively different projects without any real shared commit history (from a dev perspective) shouldn’t they be different repositories in the PsychoPy organization?

This also enables people to use Github issues, PRs, etc. specifically for the JS project without being diluted by problems/issues in the Python version.


Yeah, maybe. The issues are:

  • the version of PsychoJS and PsychoPy need to be tightly tied together in the releases - otherwise the code being output by Builder could be for the wrong version of PsychoJS. That might be less important int he future but right now I expect PsychoJS will be somewhat “fluid”. I guess we could do this with something like pip version requirements but I’m not sure it would be a tight enough bind. If we need to bake a psychojs version into the psychopy release then its easier to keep them in the same project.
  • right now we don’t really anticipate people using PsychoJS independently of PsychoPy. It’s possible to do that, of course, but we haven’t provided any docs and that hasn’t been the initial goal
  • the importance of github PRs being independent doesn’t seem very important to me but maybe it should be?

I mean, my comments stem from my understanding of how things work in more traditional software engineering environments, but for specialty software like PsychoPy the needs and practices may be different. Nonetheless I believe observing the traditional practices may be beneficial to this project as well.

  1. If PsychoJS needs to be tied to PsychoPy and pip version pinning isn’t sufficient I feel that means the versioning system in PsychoPy needs to be re-evaluated. Major version numbers should only be increased for major changes that break backwards compatibility, minor version numbers introduce new features that are backwards compatible, and patch numbers are bug fixes, or something along those lines. ( I’m not sure how PsychoPy currently does versioning, but perhaps this could be a good idea?

    Regarding baking one into the other this can be achieved with an appropriate build system or using git submodules. At the very least, the API shouldn’t change in such a backwards-incompatible way so as to break old versions of either library outside of a major revision.

  2. Ideally this should be an end goal and structuring the project to make it easier to achieve would be a good idea in my book, but I defer to your judgement.

  3. The idea behind this is to have the repositories be conceptually related to only one independent project. Therefore when you look through the commits, issues, and PRs, they are only referring to things with one project, not two different ones. It makes it easier to reason about the code and how it changes over time.


Yes, PsychoPy has used semantic versioning exactly as you describe for about a decade :wink: (see

The more I think about it using pip for PsychoJS as a separate module makes no sense at all. PsychoJS contains no python code so it would be crazy to include it as a Python module just so that PsychoPy had access.

Git submodules look like the ideal solution and they’re new to me. I’ll look into how they work. Can’t work out when they appeared in git but definitely not when I first started! Github apparently made a blog post about them just 3 weeks ago, so I guess I’m not the only one new to this!

So thanks for the heads-up on that


We’re testing this out now. That is, I’ve created the new repository here:

We’ll see how it goes but looks fine so far

1 Like