[micromamba] pip can't find requirements.txt in current working directory

[wholtz]

$ uname -a
Darwin WJHoltz-M64.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64
$ micromamba --version
0.24.0
$ cat environment.yaml 
name: test 
channels: 
  - conda-forge 
dependencies:
  - python
  - pip: 
    - -r requirements.txt
$ cat requirements.txt 
pytest
$ micromamba create -y --quiet -f environment.yaml 
  Package                Version  Build               Channel                  Size
─────────────────────────────────────────────────────────────────────────────────────
  Install:
─────────────────────────────────────────────────────────────────────────────────────

  + bzip2                  1.0.8  h0d85af4_4          conda-forge/osx-64     Cached
  + ca-certificates  2022.5.18.1  h033912b_0          conda-forge/osx-64     Cached
  + libffi                 3.4.2  h0d85af4_5          conda-forge/osx-64     Cached
  + libzlib               1.2.12  h6c3fc93_0          conda-forge/osx-64     Cached
  + ncurses                  6.3  h96cf925_1          conda-forge/osx-64     Cached
  + openssl                3.0.3  hfe4f2af_0          conda-forge/osx-64     Cached
  + pip                   22.1.2  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + python                3.10.4  h1cc4136_0_cpython  conda-forge/osx-64     Cached
  + python_abi              3.10  2_cp310             conda-forge/osx-64     Cached
  + readline                 8.1  h05e3726_0          conda-forge/osx-64     Cached
  + setuptools            62.3.2  py310h2ec42d9_0     conda-forge/osx-64     Cached
  + sqlite                3.38.5  hd9f0692_0          conda-forge/osx-64     Cached
  + tk                    8.6.12  h5dbffcc_0          conda-forge/osx-64     Cached
  + tzdata                 2022a  h191b570_0          conda-forge/noarch     Cached
  + wheel                 0.37.1  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + xz                     5.2.5  haf1e3a3_1          conda-forge/osx-64     Cached
  + zlib                  1.2.12  h6c3fc93_0          conda-forge/osx-64     Cached

  Summary:

  Install: 17 packages

  Total download: 0 B

─────────────────────────────────────────────────────────────────────────────────────

ERROR: Could not open requirements file: [Errno 2] No such file or directory: '/var/folders/62/s7y43_hs417fpf5php4jydz40000gp/T/requirements.txt'
critical libmamba pip failed to install packages
$ 

[sfariaNG]

I ran into this as well, for some reason it's attempting to create this file in my current directory which is read-only instead of /tmp. Can this be changed to use /tmp instead of pwd?

[jonashaag]

We should fix this, do you want to try to come up with an initial patch?

[sfariaNG]

@jonashaag I can take a stab at it if you point me in the right direction.

[francisjeanneau]

@wholtz Did you find a workaround for what you were trying to achieve in the end? Similar issue here: micromamba searching for requirements.txt in /tmp/ folder.

ERROR: Could not open requirements file: [Errno 2] No such file or directory: '/tmp/requirements.txt'

I wish I could specify a relative path to requirements.txt which resides somewhere else in the project.

[AngryMaciek]

I have also run into this issue today. I have some dependencies specified in environment.yml file which also points to a requirements.txt inside, via pip: key. I run conda env create and get:

Preparing transaction: ...working... done
Verifying transaction: ...working... done
Executing transaction: ...working... done
Installing pip dependencies: ...working... Ran pip subprocess with arguments:
['/mambaforge/envs/package-dev/bin/python', '-m', 'pip', 'install', '-U', '-r', '/tmp/condaenv.2tineofl.requirements.txt', '--exists-action=b']
Pip subprocess output:

Pip subprocess error:
ERROR: Could not open requirements file: [Errno 2] No such file or directory: '/tmp/requirements.txt'

failed

CondaEnvException: Pip failed

EDIT:

An obvious solution is to: cp requirements.txt /tmp/. which indeed solves the problem, still this is something strange...

EDIT2:

OK, I solved it. It turns out it in my case it was that my current user did not have write permissions in the CWD; I'm working in a Docker container and the user/group/permission stuff is a little confusing...