Noarch

[ilanschnell]

Improved the creation of Python noarch packages quite a bit. The Python noarch packages handle examples, site-packages files and scripts cross platform. They work with the existing conda install process. These noarch packages, should go into the noarch directory, alongside (linux-64, linux-32, 'osx-64, etc.) in the channel. Conda will look for packages in the noarch directory, this is implemented in PR 1120 conda/conda#1120.
To build a noarch package, all which needs to be one is to add

build:
  noarch_python: True

the the meta.yaml files of the recipe. The way it works is the following. The package is build, using build.sh as usual, and afterwards the files are rearranged into a different file structure, and a pre-link Python script is generated, which (upon install) does the actual linking. As a result, the info/files is empty.

[ijstokes]

1. How are noarch dependencies handled/specified?
2. To me, it would make more sense to have platform: noarch (and alternatively things like platform: linux-64 or platform: win-32), instead of noarch: True. Is there a reason this isn't preferable? I don't know how the binstar build-server works, but presumably some kind of mechanism like this must already exist so a proto-package can be submitted to binstar and then cross-compiled into the specified platforms (perhaps using platform-specific dependencies or build process?)

[ilanschnell]

1. The noarch packages specify the dependencies as any other package would. However, since the same package is used on all platforms and for all Python versions, this means that the dependencies also have to be same across platforms and for Python versions.
2. Conda packages have such platform information. However, the noarch: True is used in the meta.yaml file in the recipe. The recipe metadata does not specify which platform to use, because the same recipe can be used on different platforms. This is also the reason why the Python version in not part of the recipe, but instead the CONDA_PY environment variable is used during the build process.

[asmeurer]

I would change the meta.yaml key to be something more Python specific, so that this is easy to generalize to other languages without confusion.

[tswicegood]

+1 for this being more Python specific. This implementation targets only python code which means I can't use it for things like npm packages that are pure JS. FWIW, that's a use case that I have.

This also doesn't solve the multi-arch problem (i.e., I can build a package on Darwin that works on Linux64 without any problems, but I can't specify the architecture. Per @ijstokes' recommendation, going down a platform: noarch pattern opens up the possibility of platform: ["linux64", "osx64"].

[ilanschnell]

Yes, this is very Python specific. I will change the key in the meta.yaml to:

build:
  noarch_python: True

However, the created package will not have Python specific metadata.

[tswicegood]

@ilanschnell any idea why the tests are failing? It doesn't appear that they've passed at all.

[asmeurer]

It's only Binstar build that's failing (erroring really). I guess the Windows build machines are down (?)

[tswicegood]

Guys, we really need to get out of the habit of merging PRs that have broken tests in them. It basically makes that red X a useless designation and trains us to question it. That's a horrible habit to get into as we'll eventually merge something that's truly broken.

[ilanschnell]

If the Windows build machines are down, what are we supposed to do?

[hargup]

@ilanschnell what is the number key supposed to do?

[asmeurer]

The build number lets you create a new build of a package without incrementing the version. conda compares versions of a package first by looking at the version string and then, if those are equal, comparing build numbers.

[wojdyr]

Regarding the option naming. noarch_python: True is for Python-specific handling. When a generic noarch is implemented (to avoid uploading the same data files 5x to anaconda), how do you suggest to name it? build/noarch: true?

Or maybe change it to noarch: python and noarch: true?

I wanted to discuss it asap, before noarch_python gets documented.

[ilanschnell]

+1 Thanks @wojdyr! I really like noarch: Python. Then we can have a single key (build/noarch).

[afeblot]

I would like a noarch package build procedure which does no assumption on what is contained in a package, and does no change on what I provide. This is what could be triggered by build/noarch:true, whereas the current behavior would belong to build/noarch: python.
Does this makes sense to somebody else?

[msarahan]

@afeblot that is very much the current implementation, put together by @soapy1 and @kalefranz in #1285 #1334 #1366. Do these not do what you want? What conda-build version are you running?

[afeblot]

@msarahan Oh yes, totally build/noarch: True and build/string: noarch made it. Thanks a lot for pointing me to this. The doc does not mention this yet.

[github-actions]

Hi there, thank you for your contribution!

This pull request has been automatically locked because it has not had recent activity after being closed.

Please open a new issue or pull request if needed.

Thanks!