Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qtpy dependencies automatically get inappropriate version constraints #46

Open
smathot opened this issue Jan 2, 2020 · 5 comments
Open

Comments

@smathot
Copy link
Contributor

smathot commented Jan 2, 2020

When qtpy is a dependency, conda build appears to automatically add version constraints that result in incompatibility. For example, building python-qnotifications results in the following index.json:

{
  "arch": null,
  "build": "py_2",
  "build_number": 2,
  "depends": [
    "pyqt >=5.12.3,<5.13.0a0",
    "python",
    "qt >=5.12.5,<5.13.0a0",
    "qtpy"
  ],
  "license": "GNU General Public License v3 (GPLv3)",
  "name": "python-qnotifications",
  "noarch": "python",
  "platform": null,
  "subdir": "noarch",
  "timestamp": 1577968165878,
  "version": "2.0.3"
}

This is incompatible with Python 2, for which these versions of PyQt are not available. This happens for all packages that have qtpy as a run dependency, which right now are python-qnotifications and python-qdatamatrix. I'm building with conda-build 3.18.11 and conda 4.7.12 on Ubuntu 19.10.

As a (deeply unsatisfying) workaround, I'm manually removing these version constraints before uploading the package. That works.

@smathot
Copy link
Contributor Author

smathot commented Jan 13, 2020

This also affects the python-qosf package.

@dschreij
Copy link
Member

This may be complicated by the fact that Python 2 is EOL and so these safeguards are there with good reasons. Wouldn't using an older version of qtpy also fix this?

@dschreij
Copy link
Member

I posted this issue in the conda-build repository (conda/conda-build#3864). They stated this has to do with https://github.com/conda-forge/pyqt-feedstock/blob/master/recipe/meta.yaml#L33.
Do you also get the packages from the conda-forge channel (Which is the channel for community packages). Related to this, there is a request now to make OpenSesame an official conda-forge package. How do you feel about this?

@smathot
Copy link
Contributor Author

smathot commented Feb 3, 2020

Do you also get the packages from the conda-forge channel (Which is the channel for community packages).

Yes, I added cogsci and conda-forge as channels.

It was not clear to me from the discussion here whether we found a solution for this?

Related to this, there is a request now to make OpenSesame an official conda-forge package. How do you feel about this?

I'm worried that this will take more time than we anticipate now, so for the moment let's not do this, and focus on things that have priority. There's also not that much to gain, because the few users of OpenSesame that use Anaconda can simply add the cogsci channel. In the long term though, I'm of course in favor of this.

@dschreij
Copy link
Member

dschreij commented Feb 3, 2020

It was not clear to me from the discussion here whether we found a solution for this?
That link point to a 404

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants