Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:05
    github-actions[bot] locked #46
  • 06:05
    github-actions[bot] labeled #46
  • 06:05
    github-actions[bot] locked #78
  • 06:04
    github-actions[bot] labeled #78
  • 06:04
    github-actions[bot] locked #11
  • 06:04
    github-actions[bot] labeled #11
  • 06:04
    github-actions[bot] locked #57
  • 06:04
    github-actions[bot] labeled #57
  • 06:04
    github-actions[bot] locked #21
  • 06:04
    github-actions[bot] labeled #21
  • 06:04
    github-actions[bot] locked #115
  • 06:04
    github-actions[bot] labeled #115
  • 06:04
    github-actions[bot] locked #20
  • 06:04
    github-actions[bot] labeled #20
  • 06:04
    github-actions[bot] locked #13
  • 06:04
    github-actions[bot] labeled #13
  • 06:04
    github-actions[bot] locked #12
  • 06:04
    github-actions[bot] labeled #12
  • 06:04
    github-actions[bot] locked #18
  • 06:04
    github-actions[bot] labeled #18
Anthony Scopatz
@scopatz
I have been trying to use it on windows, where everything is weird
Ray Donnelly
@mingwandroid
I'll try to kick the tyres a bit later, for sure it'll work better on the other OSes and it is still a bit of an experiment. Isuru didn't want it integrated into conda-build really but I want conda-build's stats reporting to tie into it via calling ccache -s. It can then report if using ccache actually did anything useful for your build or not so you can investigate that (maybe try the other methods, or modify bld.bat/build.sh etc)
Joe Graham
@josgraha
hello all, getting an error when I run conda-build --no-anaconda-upload --python=3.6 .
Scripts/.packagename-pre-link.sh not in info/files
this is from tar check.py, any clues where to look? not too familiar with build errors yet (this is for a noarch py>=3) package
2 replies
I guess I'm probably more interested in how tarcheck.py works and what the inputs are
Matthew R. Becker
@beckermr
@jjhelmus @mingwandroid @chenghlee have you all looked into code signing on osx-arm64? @isuruf @erykoff and I are hitting roadblocks due to missing or invalid signatures coming out of conda-build.
28 replies
J. Emiliano Deustua
@edeustua
This message was deleted
mattchan-tencent
@mattchan-tencent
Hi, is there any guidance on how to use pytest as a part of a conda build recipe?
5 replies
It seems like it's meant to be used with tox for installed packages, but there's significant overlapping functionality with conda build in that case...
mattchan-tencent
@mattchan-tencent
I guess one more question. What about the cases with cmake tests? Do you just run them after the compile in the build phase? Or is there some way to get all the sources, binaries, etc into the test phase?
mattchan-tencent
@mattchan-tencent
(the tests are run with "make test")
Jonathan J. Helmus
@jjhelmus
Typically cmake/autotools tests are run as part of the build rather than in the test phase.
Ray Donnelly
@mingwandroid
@mattchan-tencent I have a preference for tests (provided they are not too expensive, size-wise and time-to-run-wise) to be added to the package itself via conda-build's test metadata. Sometimes this is easy, but sometimes not. Getting the tests into the package itself allows that package to be tested later in different environments which will help greatly with tracking down unexpected behaviours (for example when you update some of the deps)
It might be an idea to split the package into package and package-tests too. Then make the test for package depend on package-tests. That way people who do not care about the tests do not suffer the costs. This would also be a good way to handle tests that are larger (and maybe take longer) .. I would love to find the time to implement multi-level testing too or perhaps giving tests some metadata against which you (or tooling) can filter them (needs_network, needs_super_user, slow_test, heavy_test, etc).
Isuru Fernando
@isuruf
Why does conda-build print warning messages twice? For eg:
No numpy version specified in conda_build_config.yaml.  Falling back to default numpy value of 1.11
WARNING:conda_build.metadata:No numpy version specified in conda_build_config.yaml.  Falling back to default numpy value of 1.11
sometimes 3 times
Multiple meta.yaml files found. The meta.yaml file in the base directory will be used.
WARNING:conda_build.utils:Multiple meta.yaml files found. The meta.yaml file in the base directory will be used.
WARNING conda_build.utils:find_recipe(1219): Multiple meta.yaml files found. The meta.yaml file in the base directory will be used.
Ray Donnelly
@mingwandroid
It'd be nice to fix I agree. No idea, the stdout/err handling is a bit complicated (mostly due to python 2 and unicode concerns and capturing and filtering..)
Ray Donnelly
@mingwandroid
I think I would like to remove this warning from conda-build
"UserWarning: The environment variable 'CONDA_FORGE' is being passed through with value 'yes'. If you are splitting build and test phases with --no-test, please ensure that this value is also set similarly at test time."
reasons: 1. these vars are passed specifically to modify build behavior (as I use them at least!), and have no bearing on tests ..
  1. If we do want this warning, well, conda-build knows if we're using --no-test or not, and we could at least keep quiet when that isn't in play.
C:\opt\conda-win-32\lib\site-packages\conda_build\environ.py:447: UserWarning: The environment variable 'PY_INTERP_LINKAGE_NATURE' is being passed through with value ''.  If you are splitting build and test phases with --no-test, please ensure that this value is also set similarly at test time.
  warnings.warn(
C:\opt\conda-win-32\lib\site-packages\conda_build\environ.py:447: UserWarning: The environment variable 'PY_INTERP_DEBUG' is being passed through with value 'no'.  If you are splitting build and test phases with --no-test, please ensure that this value is also set similarly at test time.
  warnings.warn(
C:\opt\conda-win-32\lib\site-packages\conda_build\environ.py:447: UserWarning: The environment variable 'OPENSSL_DIR' is being passed through with value '%PREFIX%\Library'.  If you are splitting build and test phases with --no-test, please ensure that this value is also set similarly at test time.
  warnings.warn(
C:\opt\conda-win-32\lib\site-packages\conda_build\environ.py:447: UserWarning: The environment variable 'SQLITE3_DIR' is being passed through with value '%PREFIX%\Library'.  If you are splitting build and test phases with --no-test, please ensure that this value is also set similarly at test time.
  warnings.warn(
C:\opt\conda-win-32\lib\site-packages\conda_build\environ.py:447: UserWarning: The environment variable 'CONDA_FORGE' is being passed through with value 'yes'.  If you are splitting build and test phases with --no-test, please ensure that this value is also set similarly at test time.
  warnings.warn(
INFO:conda_build.metadata:Attempting to finalize metadata for python
two ones, no two, oh well.
Isuru Fernando
@isuruf
since we started adding rpath on macos, all shared libraries and executables needs relocation whereas on Linux due to the use of $ORIGIN, it's not needed. is there something we can do on macos?
Cheng H. Lee
@chenghlee
IIRC, macOS has @loader_path and @executable_path which are roughly analogous to $ORIGIN, but it's been a while since I've looked at the developer docs.
Ray Donnelly
@mingwandroid
Indeed, we don't rely on any runtime relocation of macOS binaries AFAIK
We patch stuff to be exe-relative
Isuru Fernando
@isuruf
Alastair Rankine
@randomphrase

Hi all, hoping someone can help me, struggling a bit with conda-build. I am trying to package a closed-source c++ library which is distirbuted as tarball. I want to accomplish a (seemingly) simple task: produce a conda package from a the headers and static libraries from this tarball. I have the following meta.yaml file:

package:
  name: my-package
  version: 1.0
source:
  url: http://path/to/tar.gz
  sha256: here
build:
  number: 0
outputs:
  - name: my-package
    script: dev-files.py

The dev-files.py file script selects the header files from the current (ie work) directory and copies them into the corresponding $PREFIX directory (I assume this is correct - it's not documented). The copy task seems to work but then the packaging job fails with this error:

Failed to rename host env directory despite sleeping and retrying. This is some Windows file locking mis-bahaviour.

Which is interesting because I'm not on Windows. Any help appreciated.

16 replies
Alastair Rankine
@randomphrase
With reference to the above issue I now believe this is an entirely spurious error message. From reading the code in question, it will always produce this error message even when the underlying move operation is entirely successful. I'll raise an issue/PR when I get some time. Thanks @nehaljwani for your help.
Ray Donnelly
@mingwandroid
A new conda-build release (3.20.4) is coming up, so if anyone wants me to review PRs for inclusion (or have bugs they feel really should be fixed) then please holler!
Isuru Fernando
@isuruf
@mingwandroid, conda/conda-build#4080
Alastair Rankine
@randomphrase
conda/conda-build#4087 but CLA not signed yet
Ray Donnelly
@mingwandroid
@randomphrase I have a fix for that too. @Isuruf, should be fine, thanks.
Matthew R. Becker
@beckermr
do we want this one @isuruf @mingwandroid @jjhelmus : conda/conda-build#4052
Ray Donnelly
@mingwandroid
Probably? I don't know a load about the current_metadata.yaml stuff though
Krishna Bhogaonker
@00krishna

Hey folks. I am getting a strange build error when using conda build. It has not happened before and googling did not yield any results. I built my package, but when uploading to anaconda.org I get this error.

Uploading nyuki-0.0.3-py_0.tar.bz2 to anaconda.org
Traceback (most recent call last):
  File "/media/krishnab/lakshmi/anaconda3/bin/conda-build", line 11, in <module>
    sys.exit(main())
  File "/media/krishnab/lakshmi/anaconda3/lib/python3.7/site-packages/conda_build/cli/main_build.py", line 474, in main
    execute(sys.argv[1:])
  File "/media/krishnab/lakshmi/anaconda3/lib/python3.7/site-packages/conda_build/cli/main_build.py", line 465, in execute
    verify=args.verify, variants=args.variants)
  File "/media/krishnab/lakshmi/anaconda3/lib/python3.7/site-packages/conda_build/api.py", line 210, in build
    notest=notest, variants=variants)
  File "/media/krishnab/lakshmi/anaconda3/lib/python3.7/site-packages/conda_build/build.py", line 3155, in build_tree
    handle_anaconda_upload(tarballs, config=config)
  File "/media/krishnab/lakshmi/anaconda3/lib/python3.7/site-packages/conda_build/build.py", line 3236, in handle_anaconda_upload
    subprocess.call(cmd + [package])
  File "/media/krishnab/lakshmi/anaconda3/lib/python3.7/subprocess.py", line 339, in call
    with Popen(*popenargs, **kwargs) as p:
  File "/media/krishnab/lakshmi/anaconda3/lib/python3.7/subprocess.py", line 800, in __init__
    restore_signals, start_new_session)
  File "/media/krishnab/lakshmi/anaconda3/lib/python3.7/subprocess.py", line 1465, in _execute_child
    executable = os.fsencode(executable)
  File "/media/krishnab/lakshmi/anaconda3/lib/python3.7/os.py", line 812, in fsencode
    filename = fspath(filename)  # Does type-checking of `filename`.
TypeError: expected str, bytes or os.PathLike object, not list

So it is execting a string or os.PathLike object, and not a list. I am not sure where this error could come coming from. Does it seem familiar to anyone. The only other thing I found in the entire build stdout is a reference to that ERROR:conda_build.utils:Failed to rename work directory despite sleeping and retrying. This is some Windows file locking mis-bahaviour. errro that someone mentioned yesterday or a few days ago.

I can share the meta.yaml file if it would be useful. Seems like the build process completed, but this message arises when uploading to anaconda.org.
Lucas Hosseini
@beauby
Any general advice for distributing nightly packages through conda? I'm leaning towards having a separate package named foo-nightly with versions 1.0.0-nightly-AAAAMMDD, but maybe there is a better solution? Ideally, I'd like the -nightly package to be incompatible with the real releases, to avoid conflicts
An other option being having a separate channel
Ray Donnelly
@mingwandroid
You can use 'labels' on anaconda.org, it's just like nested channels really
But you probably do want different filenames. You can see how we address that in the AD python-recipe here: https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/meta.yaml
follow PY_INTERP_DEBUG
Lucas Hosseini
@beauby
@mingwandroid Thanks, I'll look into that! Would I be correct to assume that conda install foo -c mychannel would install only packages tagged with "main", and conda install foo -c mychannel/labels/nightly would install only packages tagged with "nightly"?
Ray Donnelly
@mingwandroid
Yeah, I think so. I don't use labels myself though, probably I should
Lucas Hosseini
@beauby
Pretty cool, if this works the way I think, it's exactly what I'm looking for. Thanks for pointing it out
Ray Donnelly
@mingwandroid
No problem!
Lucas Hosseini
@beauby
Yeah I'm not 100% sure what the role of the build string is – it has to be unique per version, but does it serve a technical purpose?
Cheng H. Lee
@chenghlee
It serves to distinguish multiple builds of the same version of a package. These may be due to changes in recipes to fix build problems, to variants of the same base recipes (e.g., choosing between py36, py37, or py38 builds of numpy), or to whatever other purpose the package maintainer chooses.