noarchpackage that will work on python 3.6, 3.7, and 3.8. Note the package uses geospatial packges like
rasterio. So the package builds just fine and imports with no error. The problem is that is will only import properly for python=3.8 now, and if I try to import it with a python 3.6 or python 3.7 environment, then it will give me these CUDA driver errors
- feature:/linux-64::__cuda==10.0=0. So is the package perhaps not really
noarch, since CUDA is a compiled extension for one of the dependencies probably.
build: noarch: python number: 0 skip: true # [py<36 ]
noarchpython. So not sure of the right place to look for the answer in the documentation. I checked https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html , but it really details how to use
noarch, but not what to do if
noarchdoes not work.
- python_abi 3.8.* *_cp38in the built package metadata that should not be there. I read the issues, but did not see any resolution. If anyone knows how to remove this odd dependency, please LMK.
conda build --no-include-recipe meta.yamlfor a python sdk app, I get ~187 of the following odd errors (warnings?). Why? Is this something to be concerned about? If so, how does one fix this? :
[...] Packaging my_sdk INFO:conda_build.build:Packaging my_sdk Packaging my_sdk-w.x.y.z-py_0 INFO:conda_build.build:Packaging my_sdk-w.x.y.z-py_0 number of files: 112 /Library/Developer/CommandLineTools/usr/bin/nm: /anaconda3/conda-bld/my_sdk_1596598276840/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libpython3.8.a(getbuildinfo.o) Invalid value (Producer: 'LLVM10.0.0' Reader: 'LLVM APPLE_1_900.0.38_0') /Library/Developer/CommandLineTools/usr/bin/nm: /anaconda3/conda-bld/my_sdk_1596598276840/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libpython3.8.a(acceler.o) Invalid value (Producer: 'LLVM10.0.0' Reader: 'LLVM APPLE_1_900.0.38_0') /Library/Developer/CommandLineTools/usr/bin/nm: /anaconda3/conda-bld/my_sdk_1596598276840/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libpython3.8.a(grammar1.o) Invalid value (Producer: 'LLVM10.0.0' Reader: 'LLVM APPLE_1_900.0.38_0') [...] /Library/Developer/CommandLineTools/usr/bin/nm: /anaconda3/conda-bld/my_sdk_1596598276840/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libpython3.8.nolto.a(xxsubtype.o) Invalid value (Producer: 'LLVM10.0.0' Reader: 'LLVM APPLE_1_900.0.38_0') /Library/Developer/CommandLineTools/usr/bin/nm: /anaconda3/conda-bld/my_sdk_1596598276840/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libpython3.8.nolto.a(frozen.o) Invalid value (Producer: 'LLVM10.0.0' Reader: 'LLVM APPLE_1_900.0.38_0')
brewdecided to upgrade XCode CLI tools?
placeholdstuff is standard. That happens to everyone. I don't know the exact details, but basically it is a way to ensure that when installing the package, they have all of that space reserved for the paths in the package. I think the
condadevelopers used to have shorter path and then that led to problems with not having the space for longer paths on some OSs, but I am not the expert on that.
placeholdstuff, I think you're right, I think I may have even asked this here a long time back & a dev commented, although the issue/solution still seems strange to me. Re. the version: unless there's a good reason to (ex: specific fix, necessary feature, severe security vulnerability, etc.) I don't like to upgrade, as things tend to break. Case in point, I don't think the
nmissues above occurred until Homebrew forced the re-installation of XCode CLI tools :confused:
Output in format: Requested package -> Available versions Package ca-certificates conflicts for: python[version='>=3.7,<3.8.0a0'] -> openssl[version='>=1.1.1g,<1.1.2a'] -> ca-certificates pytest -> python[version='>=2.7,<2.8.0a0'] -> ca-certificates Package python conflicts for: pytest -> attrs[version='>=17.4.0'] -> python[version='>=3.4'] eqasm-parse==0.1=openmp -> python[version='>=3.8,<3.9.0a0'] pytest -> python[version='>=2.7,<2.8.0a0|>=3.6,<3.7.0a0|>=3.7,<3.8.0a0|>=3.8,<3.9.0a0|>=3.5,<3.6.0a0'] python[version='>=3.7,<3.8.0a0']
conda-build. So the package gets build when when trying to install that package into the test environment, conda cannot find the newly built package. So the command according to the conda build docs is
conda install --use-local <packagename>. That did not work, nor did the alternative
conda install -c local <packagename>. I was hunting through feedstocks but did not see anyone using this code, so hopefully someone knows the answer.
conda-buildfrom a non-root environment and trying to install the package using
- bash miniconda.sh -b -p $HOME/miniconda - source "$HOME/miniconda/etc/profile.d/conda.sh" - hash -r - conda config --set always_yes yes --set changeps1 no - conda update -q conda - conda info -a - conda install conda-build - conda create -q -n test-environment python=$TRAVIS_PYTHON_VERSION conda pytest six pytest-cov pytest-mock - conda activate test-environment - conda build packaging/ - conda install --use-local <packagename>
.jardependencies? (I assume native jar dependencies currently aren't handled and would need to just be bundled with the JVM-based app itself?)...
requirements.txt. As I understand it, we are supposed to keep
condapackages/environments separate from
pipstuff, as much as possible--I read @jjhelmus blog post on this. Now one thing that was not clear in the docs was the relationship between the
requirements.txt. I have packages listed in
requirements.txtso that I can test them in Travis for regular CI -- where I can use
conda install --file requirements.txtand it will find the packages in the conda channel. But for package building, if I have the same packages listed in the Host and Runtime section of
requirements.txt, will that cause issues? Like will the package--say
numpyfor example--get installed by conda and then upgraded by pip, or some other weird behavior? Or if a package is listed in
conda-buildskip that same reference in
requirements.txt? I was trying to find a good example feedstock for this, but was not sure where to look.
conda-builddoes not bother with
requirements.txt, that is helpful. So then if I list non-conda packages in the
conda-buildwill know to use
pipto install those, or do I have to specify this somewhere? Sorry, just trying to make sure I am thorough in my understanding. Thanks again.
pip install --no-depswith your build script (
bld.bat), but that's a not 100% reliable option.
condanow, those are
pytest-cases. So if I wanted to install those in my
condabuilt package, what would be the right way to do that. Would I include a script that does a
pip install dhash --no-depsor something like that?