[wip] noarch - Githubissues

conda-forge / jupyter_core-feedstock

A conda-smithy repository for jupyter_core.

BSD 3-Clause "New" or "Revised" License

2 stars 21 forks source link

[wip] noarch #49

Closed minrk closed 5 days ago

minrk commented 2 years ago

Challenge is that we need 3 builds, two for Windows:

unix: no pywin32
windows + cpython: pywin32
windows + pypy: no pywin32 (actually the same as unix)

Trying:

linux noarch builds depend on cpython and pywin32-on-windows to get builds 1 and 2
windows builds depend on pypy and not pywin32 to get build 3

Need to think a bit how to verify these work (the main thing to accomplish is that the windows + pypy build isn't an installation candidate on Windows + cpython, which would omit the pywin32 dependency)

closes #44

conda-forge-linter commented 2 years ago

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [24, 32]
noarch packages can't have selectors. If the selectors are necessary, please remove noarch: python.

conda-forge-linter commented 2 years ago

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

noarch packages can't have selectors. If the selectors are necessary, please remove noarch: python.

bollwyvl commented 2 years ago

Without having to yank versions, is there something we could do on pywin32-on-windows that would help this situation?

windows + pypy build isn't an installation candidate on Windows + cpython,

Could have run_constrained to impossible versions?

noarch packages can't have selectors.

It may be clearer (and linter-appeasing) to use redundant jinja {% if %} blocks instead of selectors.

minrk commented 2 years ago

is there something we could do on pywin32-on-windows that would help this situation?

A pywin32-on-windows-cpython would work for us here.

If pywin32-on-windows encapsulated the pypy condition, too, since pywin32 doesn't work on PyPy, that would let us have a single noarch package for jupyter-core and anything with similar pywin32 dependency. Currently, depending on pywin32-on-windows prevents installation with pypy, which may be a good thing for most packages that depend on it (i.e. if you actually require pywin32, you don't support pypy). But packages that work on pypy necessarily must also work without pywin32, as is the case for jupyter-core.

bollwyvl commented 2 years ago

No luck over on https://github.com/conda-forge/pywin32-on-windows-feedstock/pull/4 yet...

isuruf commented 2 years ago

Why not remove pywin32 dependency altogether even for windows+cpython?

minrk commented 2 years ago

Why not remove pywin32 dependency altogether even for windows+cpython?

I'm not sure I follow. It is a dependency of the package on that platform.

isuruf commented 2 years ago

There is a fallback even for windows+cpython that works when pywin32 is not found right?

minrk commented 2 years ago

There is a degraded fallback, yes. So we could do that, I guess, and only use pywin32 if available and hope something else depends on it.