You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The noarch: python directive in the build section is handy, but since the build step does not differentiate between what kind of distribution package is built, conda packages built with egg using this directive can have issues. For example, egg does leave behind python version information in the package:
If another package adds this package as a dependency and conda-build is not being called in python 3.6 then when 'python setup.py install' is called, easy_install will try to bring in the dependency from pypi and cause conda-build to fail. If a wheel is used instead, the resulting conda package is without any python version information:
The noarch: python directive in the build section is handy, but since the build step does not differentiate between what kind of distribution package is built, conda packages built with egg using this directive can have issues. For example, egg does leave behind python version information in the package:
If another package adds this package as a dependency and conda-build is not being called in python 3.6 then when 'python setup.py install' is called, easy_install will try to bring in the dependency from pypi and cause conda-build to fail. If a wheel is used instead, the resulting conda package is without any python version information:
Note that the egg-info issue is alluded to just a few paragraphs down in the documentation:
https://conda-forge.org/docs/meta.html#single-version-externally-managed
I propose that the docs suggest that when noarch: python is used to either use pip or setuptools with wheel
A pip example:
A wheel/setuptools example:
The text was updated successfully, but these errors were encountered: