Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 22:12
    ChrisBarker-NOAA commented #3828
  • 20:27
    ChrisBarker-NOAA commented #3828
  • 20:25
    marcelotrevisani labeled #3828
  • 20:25
    marcelotrevisani commented #3828
  • 20:24
    marcelotrevisani commented #3827
  • 20:21
    marcelotrevisani labeled #3827
  • 20:21
    marcelotrevisani commented #3827
  • 18:21
    ChrisBarker-NOAA opened #3828
  • Dec 09 22:50
    katietz commented #3826
  • Dec 09 22:48
    katietz synchronize #3826
  • Dec 09 22:31
    katietz synchronize #3826
  • Dec 09 21:47
    katietz synchronize #3826
  • Dec 09 20:40
    msarahan edited #3826
  • Dec 09 20:40
    msarahan commented #3826
  • Dec 09 20:10
    cla-bot[bot] labeled #3826
  • Dec 09 20:10
    katietz opened #3826
  • Dec 09 19:21

    conda-bot on gh-pages

    docs for pr 3825 (compare)

  • Dec 09 19:21

    conda-bot on gh-pages

    remove docs for pr 3825 (compare)

  • Dec 09 19:20

    conda-bot on gh-pages

    docs for pr 3825 (compare)

  • Dec 09 19:19
    marcelotrevisani closed #3825
Matthew R. Becker
@beckermr
reading the source has been less than enlightening
for me
Andrew Annex
@AndrewAnnex
could someone give me some feedback on #3773 and respond to my issue #3776 ? I could also attempt to fix #3776 if someone can point me to the right place in the codebase
Dan Cotruta
@catmandi_twitter
hi all
i am having some trouble building a simple conda package to use in a local channel
but conda index is not picking up my package
Douglas Lowe
@douglowe
Can anyone tell me where I'm going wrong with my subpackages here: https://github.com/UoMResearchIT/staged-recipes/blob/prismatic_subpackages/recipes/prismatic/meta.yaml
I can't get the main package to load the subpackages as dependencies, nor do the subpackages load any dependencies other than libcxx. I've tried to follow the documentation (https://conda.io/projects/conda-build/en/latest/resources/define-metadata.html#outputs-section) but what is suggested there just doesn't seem to work.
Ray Donnelly
@mingwandroid
do you want the gui package to depend upon the cli one at runtime here?
look at the xgboot example
Matthew R. Becker
@beckermr
I have a very basic question about conda build
here is a snippet from pytest installed in the host section
#!/usr/bin/env python
# EASY-INSTALL-ENTRY-SCRIPT: 'pytest==3.6.2','console_scripts','pytest'
__requires__ = 'pytest==3.6.2'
import re
import sys
from pkg_resources import load_entry_point

if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(
        load_entry_point('pytest==3.6.2', 'console_scripts', 'pytest')()
    )
why is it using /usr/bin/env instead of the full host prefix here?
FWIW, on a normal install, this is simply the path of the env.
Matthew R. Becker
@beckermr
And my related question is whether or not I can somehow force conda to do that during conda-build
Matthew R. Becker
@beckermr
ah this is related to the length of the lines
the conda build ones are too long for most systems to deal with
the fun edge case here is that if you are working on a build on OSX that is doing somewhat dumb things with DYLD_LIBRARY_PATH, then you end up with the /usr/bin/env invoking SIP and breaking everything
blarg
Andrew Annex
@AndrewAnnex
thanks for merging in #3773, I believe that will fix my conda-forge feedstock once a new release is made, how soon until 3.8.11?
Ray Donnelly
@mingwandroid
Well, IMHO /usr/bin/env python is the correct invocation in that we respect and use PATH and not having to rewrite files per-env is a saving.
Jonathan J. Helmus
@jjhelmus
@beckermr That snippet is created by setuptools/pip not conda-build/conda. Entry points created by conda do not use pkg_resources, https://github.com/conda/conda/blob/4.7.12/conda/gateways/disk/create.py#L85-L106
Matthew R. Becker
@beckermr
Most of it is but not the shebang line
Let me show you from some packages
check out the pytest package here: https://anaconda.org/conda-forge/pytest/files
here is the contents of the command line util
(base) localhost:pytest-5.2.1-py37_0 Matt$ cd bin/
(base) localhost:bin Matt$ cat pytest 
#!/opt/anaconda1anaconda2anaconda3/bin/python

# -*- coding: utf-8 -*-
import re
import sys

from py.test import main

if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(main())
Notice that the #! line is the text that conda replaces with the prefix
here is what pytest looks like installed locally on my machine
(I have it in my base env)
(base) localhost:bin Matt$ cat ~/miniconda3/bin/pytest
#!/Users/Matt/miniconda3/bin/python

# -*- coding: utf-8 -*-
import re
import sys

from py.test import main

if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(main())
now it has the exact path to python
Matthew R. Becker
@beckermr
now check out this really silly env
(base) localhost:bin Matt$ conda create -n gggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg python=3.7 pytest
Collecting package metadata (current_repodata.json): done
Solving environment: done

## Package Plan ##

  environment location: /Users/Matt/miniconda3/envs/gggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg

  added / updated specs:
    - pytest
    - python=3.7


The following NEW packages will be INSTALLED:

  atomicwrites       conda-forge/noarch::atomicwrites-1.3.0-py_0
  attrs              conda-forge/noarch::attrs-19.3.0-py_0
  bzip2              conda-forge/osx-64::bzip2-1.0.8-h01d97ff_1
  ca-certificates    conda-forge/osx-64::ca-certificates-2019.9.11-hecc5488_0
  certifi            conda-forge/osx-64::certifi-2019.9.11-py37_0
  importlib_metadata conda-forge/osx-64::importlib_metadata-0.23-py37_0
  libcxx             conda-forge/osx-64::libcxx-9.0.0-h89e68fa_1
  libffi             conda-forge/osx-64::libffi-3.2.1-h6de7cb9_1006
  more-itertools     conda-forge/noarch::more-itertools-7.2.0-py_0
  ncurses            conda-forge/osx-64::ncurses-6.1-h0a44026_1002
  openssl            conda-forge/osx-64::openssl-1.1.1c-h01d97ff_0
  packaging          conda-forge/noarch::packaging-19.2-py_0
  pip                conda-forge/osx-64::pip-19.3.1-py37_0
  pluggy             conda-forge/osx-64::pluggy-0.13.0-py37_0
  py                 conda-forge/noarch::py-1.8.0-py_0
  pyparsing          conda-forge/noarch::pyparsing-2.4.2-py_0
  pytest             conda-forge/osx-64::pytest-5.2.1-py37_0
  python             conda-forge/osx-64::python-3.7.3-h93065d6_1
  readline           conda-forge/osx-64::readline-8.0-hcfe32e1_0
  setuptools         conda-forge/osx-64::setuptools-41.4.0-py37_0
  six                conda-forge/osx-64::six-1.12.0-py37_1000
  sqlite             conda-forge/osx-64::sqlite-3.30.1-h93121df_0
  tk                 conda-forge/osx-64::tk-8.6.9-h2573ce8_1003
  wcwidth            conda-forge/noarch::wcwidth-0.1.7-py_1
  wheel              conda-forge/osx-64::wheel-0.33.6-py37_0
  xz                 conda-forge/osx-64::xz-5.2.4-h1de35cc_1001
  zipp               conda-forge/noarch::zipp-0.6.0-py_0
  zlib               conda-forge/osx-64::zlib-1.2.11-h0b31af3_1006


Proceed ([y]/n)? y

Preparing transaction: done
Verifying transaction: done
Executing transaction: done
#
# To activate this environment, use
#
#     $ conda activate gggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg
#
# To deactivate an active environment, use
#
#     $ conda deactivate

(base) localhost:bin Matt$ conda activate gggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg
(gggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg) localhost:bin Matt$ cat `which pytest`
#!/usr/bin/env python

# -*- coding: utf-8 -*-
import re
import sys

from py.test import main

if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(main())
notice that for really long env names, conda is putting in /usr/bin/env for the prefix
all of the env names when running conda build exceeed ~128 characters
and hence they get set to /usr/bin/env
and thus on mac they trigger SIP behavior
Matthew R. Becker
@beckermr
One way around this would be to map every env to a short random hash.
But I think this is an edge case that doesn’t need to be handled
Douglas Lowe
@douglowe
@mingwandroid thanks for the link. In this case I don't need the gui package to depend on the cli one (though this might change for the linux or windows packages).
Jonathan J. Helmus
@jjhelmus
https://github.com/conda/conda/blob/4.7.12/conda/core/portability.py#L155-L175 is replacing the long shebang lines for portability. Most platforms/distribution have some limit on the length of the shebang and using #!/usr/bin/env python in those cases. Adding a configuration option to override this rewrite would be reasonable.
Matthew R. Becker
@beckermr
yup I found the old github issue where this was discussed
I like the idea of a config override
OTOH, I put in a custom shim in my build that solved this particular issue
Matthew R. Becker
@beckermr
@jjhelmus there does seem to be some interest in a config option to turn off the replacement
should I make an issue?