search

conda-forge / frozendict-feedstock

A conda-smithy repository for frozendict.
BSD 3-Clause "New" or "Revised" License
0 stars 9 forks source link

Added noarch build #26

Closed Marco-Sulla closed 2 years ago

Marco-Sulla commented 2 years ago
conda-forge-linter commented 2 years ago

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

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Marco-Sulla commented 2 years ago

I don't understand. It seems it continues to build a noarch package for every architecture... Have I to try and merge? What do you suggest?

ltalirz commented 2 years ago

Let me ask the experts on https://gitter.im/conda-forge/conda-forge.github.io what the suggested route is

bollwyvl commented 2 years ago

@conda-forge-admin please rerender

bollwyvl commented 2 years ago

continues to build a noarch package for every architecture...

yep: the multi-output approach will always build all of them. It's possible to use some jinja magic, to force just one build by e.g. 

{% set build_noarch = False %}
{% set build_noarch = True %}  # [some selector]
...
outputs:
  {% if build_noarch}
  - name: frozendict-noarch
    ...
  {% endif %}

But.... what is the motivation here? A downstream that needs frozendict would not be satisfied with frozendict-noarch.

It is possible to build multiple, like-named packages by changing something else (usually the build number) but this can be more confusing, and usually reserved for packages that would help lots of other packages stay noarch: python... but usually, if there is a performance-related compiled component, it's worth keeping that as the preferred default, if at all possible.

Marco-Sulla commented 2 years ago

Ok, thank you ltalirz and bollwyvl, I think I'll merge as-is :)

Marco-Sulla commented 2 years ago

Excuse me, yesterday was late and I didn't understand what you wrote. The fact is that if I name a build frozendict-noarch, the wheel will have this name, right? So the only chance I have is to change the build number? It will not reset to zero by the bot? This way I'll have a frozendict-VERSION-py3-none-any.whl, or it will create a noarch wheel for every py version?

bollwyvl commented 2 years ago

name a build frozendict-noarch, the wheel will have this name, right?

Yes, this yielded:

and one would have to conda install -c conda-forge frozendict-noarch to get this file. it could even be installed next to frozendict, with... unpredictable results.

only chance I have is to change the build number?

Well... it's the "build string" which is usually made of the build number and a semi-opaque hash which includes things like the compiler used. the python major, for historical reasons, also shows up.

It will not reset to zero by the bot

If one "colors within the lines," it can still figure things out... a variable named build_number appears to get used.

noarch wheel for every py version?

Yes, this is currently creating a noarch wheel for each with slightly different hashes, but otherwise no differences... as none of them have any dependencies (other than python), which one gets installed is undefined.

Which again begs the question: why do you want noarch packages, in addition to per-python-per-platform builds?

Marco-Sulla commented 2 years ago

Good question. The answer is simple: noarch build supports Python 3.6+ on every OS that can run Python. The other builds supports Linux, Windows and MacOS and Python 3.7 - 3.10

Marco-Sulla commented 2 years ago

Well, I tried as you suggested in this pull request: https://github.com/conda-forge/frozendict-feedstock/pull/28/files It didn't build the package for python 3.10 on Linux. It seems that if the output has the same name, the highest build number "wins".