[bug] conan upload errors out during check_upstream

[lhocmf]

Environment details

• Operating System+version: Windows Server 2019, Windows 10
• Compiler+version: MSVC 2022
• Conan version: 2.0.9
• Python version: 3.11

Steps to reproduce

Given two distinct repositories (staging and production):

1. create a package a using a python_requires a_requires.
2. upload the a_requires to both repositories, and a to staging.
3. go into a new, empty conan cache
4. run conan download --remote staging *:*
5. run conan upload --remote production *

It used to work like this in the past, I'm not sure whether this behavior changed during the upgrade to conan 2.0 or in between conan 2.0.x updates.

Debug hints

It looks like no remotes are being passed in the call to app.loader.load_basic(conanfile_path) in check_upstream, which causes the given error, possibly when trying to find the python_requires.

Logs

ERROR: 'NoneType' object is not iterable
Traceback (most recent call last):
  File "C:\Python311\Lib\site-packages\conan\cli\cli.py", line 272, in main
    cli.run(args)
  File "C:\Python311\Lib\site-packages\conan\cli\cli.py", line 172, in run
    command.run(self._conan_api, args[0][1:])
  File "C:\Python311\Lib\site-packages\conan\cli\command.py", line 125, in run
    info = self._method(conan_api, parser, *args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Python311\Lib\site-packages\conan\cli\commands\upload.py", line 88, in upload
    conan_api.upload.check_upstream(package_list, remote, args.force)
  File "C:\Python311\Lib\site-packages\conan\api\subapi\upload.py", line 25, in check_upstream
    conanfile = app.loader.load_basic(conanfile_path)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Python311\Lib\site-packages\conans\client\loader.py", line 38, in load_basic
    return self.load_basic_module(conanfile_path, graph_lock, display, remotes,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Python311\Lib\site-packages\conans\client\loader.py", line 60, in load_basic_module
    self._pyreq_loader.load_py_requires(conanfile, self, graph_lock, remotes,
  File "C:\Python311\Lib\site-packages\conans\client\graph\python_requires.py", line 68, in load_py_requires
    py_requires = self._resolve_py_requires(py_requires_refs, graph_lock, loader, remotes,
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Python311\Lib\site-packages\conans\client\graph\python_requires.py", line 86, in _resolve_py_requires
    resolved_ref = self._resolve_ref(requirement, graph_lock, remotes, update)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Python311\Lib\site-packages\conans\client\graph\python_requires.py", line 105, in _resolve_ref
    self._range_resolver.resolve(requirement, "py_require", remotes, update)
  File "C:\Python311\Lib\site-packages\conans\client\graph\range_resolver.py", line 34, in resolve
    remote_resolved_ref = self._resolve_remote(search_ref, version_range, remotes, update)
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Python311\Lib\site-packages\conans\client\graph\range_resolver.py", line 75, in _resolve_remote
    for remote in remotes:
TypeError: 'NoneType' object is not iterable

[lhocmf]

Changing this line

            conanfile = app.loader.load_basic(conanfile_path)

to

            conanfile = app.loader.load_basic(conanfile_path, remotes=[remote])

fixes my use-case, but might not be a complete fix (in case the python_requires is not on the targeted remote).

[memsharded]

Hi @lhocmf

Thanks for your detailed report and clear instructions, that really helps :)

This is indeed a bug, because every trace is a bug. It only happens for conan download flow, when the python_requires are not in the cache, because every other flow (create, install, info) will obtain the python_requires and cache it.

We are discussing what would be the best approach, and it seems that it makes sense to let Conan resolves the python_requires in the defined remotes at the moment, it should be easy to fix, assigning it for next 2.0.10 (I'll do a test right now)

[memsharded]

The enabled_remotes logic is already being used in conan upload for the resolution of missing sources pre-upload. So I think it makes sense to apply the same logic for resolving python_requires, I have proposed that fix in #14511

[memsharded]

#14511 merged, it will be in next 2.0.10