internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: conan-io/conan

Issue:
[feature] "The recipe is constraining settings." error should name the recipe 
When installing via a conanfile, the "ERROR: The recipe is constraining settings." message includes details
about the setting that was constrained, but not the recipe that did it.

It would be helpful if the message also named the recipe, so the user doesn't have to search through all 
the recipes of the whole tree to find which one is constraining that setting.

The implementation at
https://github.com/conan-io/conan/blob/develop/conans/model/conan_file.py#L71
already has access to the recipe's name (conanfile.display_name), 
so it would be easy to add this to the error message.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).



Discussion:
This should be an easy feature, feel free to submit a PR with the required change 🚀 

Resolving patch:
diff --git a/conans/model/conan_file.py b/conans/model/conan_file.py
--- a/conans/model/conan_file.py
+++ b/conans/model/conan_file.py
@@ -68,7 +68,8 @@ def create_settings(conanfile, settings):
         settings.constraint(current)
         return settings
     except Exception as e:
-        raise ConanInvalidConfiguration("The recipe is constraining settings. %s" % str(e))
+        raise ConanInvalidConfiguration("The recipe %s is constraining settings. %s" % (
+                                        conanfile.display_name, str(e)))
 
 
 @contextmanager


Test patch:
Repository: conan-io/conan

Issue:
[bug] iOS toolchain generator forces signature handling when using the generated toolchain file
As a user, I want to be able to generate iOS frameworks without being forced to add a signature on the generated frameworks, since this might wants to be done by the frameworks consumer.

### Environment Details (include every applicable attribute)
  * Operating System+version:
  * Compiler+version: Not relevant
  * Conan version: 1.33 and above
  * Python version: all supported ones 

### Steps to reproduce (Include if Applicable)

Use `generate` for generating a toolchain flile.

The current toolchain sets `CMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM` to a dummy value, and this forces users of generated toolchain files to implement a code signature routine in their cmake files.
But it has to be possible to generate frameworks without adding signature.

Please see also https://github.com/leetal/ios-cmake/issues/86 and the fix in https://github.com/leetal/ios-cmake/pull/94

[bug] iOS toolchain generator forces signature handling when using the generated toolchain file
As a user, I want to be able to generate iOS frameworks without being forced to add a signature on the generated frameworks, since this might wants to be done by the frameworks consumer.

### Environment Details (include every applicable attribute)
  * Operating System+version:
  * Compiler+version: Not relevant
  * Conan version: 1.33 and above
  * Python version: all supported ones 

### Steps to reproduce (Include if Applicable)

Use `generate` for generating a toolchain flile.

The current toolchain sets `CMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM` to a dummy value, and this forces users of generated toolchain files to implement a code signature routine in their cmake files.
But it has to be possible to generate frameworks without adding signature.

Please see also https://github.com/leetal/ios-cmake/issues/86 and the fix in https://github.com/leetal/ios-cmake/pull/94



Discussion:

Resolving patch:
diff --git a/conan/tools/cmake/ios.py b/conan/tools/cmake/ios.py
--- a/conan/tools/cmake/ios.py
+++ b/conan/tools/cmake/ios.py
@@ -17,9 +17,6 @@ class CMakeiOSToolchain(CMakeToolchainBase):
             # Setting CMAKE_OSX_SYSROOT SDK, when using Xcode generator the name is enough
             # but full path is necessary for others
             set(CMAKE_OSX_SYSROOT {{ CMAKE_OSX_SYSROOT }})
-            if(NOT DEFINED CMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM)
-              set(CMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM "123456789A" CACHE INTERNAL "")
-            endif()
         {% endblock %}
     """)
 


Test patch:
Repository: conan-io/conan

Issue:
Remove removal of "sh" from path for MinGW in CMake
New conan.tools.cmake CMake helper contains:

```python
 if is_windows_mingw:
                with tools.remove_from_path("sh"):
                    self._conanfile.run(command)
```

This is no longer necessary, can be replaced by ``set(DCMAKE_SH="CMAKE_SH-NOTFOUND")``. Please remove it and add a red/green test for it.


Discussion:

Resolving patch:
diff --git a/conan/tools/cmake/cmake.py b/conan/tools/cmake/cmake.py
--- a/conan/tools/cmake/cmake.py
+++ b/conan/tools/cmake/cmake.py
@@ -79,17 +79,15 @@ def configure(self, source_folder=None):
             self._conanfile.package_folder.replace("\\", "/"),
             source)
 
+        if platform.system() == "Windows" and self._generator == "MinGW Makefiles":
+            arg_list += ' -DCMAKE_SH="CMAKE_SH-NOTFOUND"'
+
         generator = '-G "{}" '.format(self._generator) if self._generator else ""
         command = "%s %s%s" % (self._cmake_program, generator, arg_list)
 
-        is_windows_mingw = platform.system() == "Windows" and self._generator == "MinGW Makefiles"
         self._conanfile.output.info("CMake command: %s" % command)
         with chdir(build_folder):
-            if is_windows_mingw:
-                with tools.remove_from_path("sh"):
-                    self._conanfile.run(command)
-            else:
-                self._conanfile.run(command)
+            self._conanfile.run(command)
 
     def _build(self, build_type=None, target=None):
         bf = self._conanfile.build_folder


Test patch:
diff --git a/conans/test/functional/toolchains/cmake/test_cmake.py b/conans/test/functional/toolchains/cmake/test_cmake.py
--- a/conans/test/functional/toolchains/cmake/test_cmake.py
+++ b/conans/test/functional/toolchains/cmake/test_cmake.py
@@ -272,6 +272,7 @@ def _verify_out(marker=">>"):
     @parameterized.expand([("Debug", "libstdc++", "4.9", "98", "x86_64", True),
                            ("Release", "libstdc++", "4.9", "11", "x86_64", False)])
     @pytest.mark.tool_mingw64
+    @pytest.mark.tool_cmake(version="3.15")
     def test_toolchain_mingw_win(self, build_type, libcxx, version, cppstd, arch, shared):
         # FIXME: The version and cppstd are wrong, toolchain doesn't enforce it
         settings = {"compiler": "gcc",
@@ -287,6 +288,7 @@ def test_toolchain_mingw_win(self, build_type, libcxx, version, cppstd, arch, sh
         self.assertIn("The C compiler identification is GNU", self.client.out)
         self.assertIn('CMake command: cmake -G "MinGW Makefiles" '
                       '-DCMAKE_TOOLCHAIN_FILE="conan_toolchain.cmake"', self.client.out)
+        assert '-DCMAKE_SH="CMAKE_SH-NOTFOUND"' in self.client.out
 
         def _verify_out(marker=">>"):
             cmake_vars = {"CMAKE_GENERATOR_PLATFORM": "",
Repository: conan-io/conan

Issue:
[feature] Consider using CMake's `include_guard()` in `conan_toolchain.cmake`
Right now at the beginning of `conan_toolchain.cmake` `CMakeToolchain` generates:

```cmake
# Avoid including toolchain file several times (bad if appending to variables like
#   CMAKE_CXX_FLAGS. See https://github.com/android/ndk/issues/323
if(CONAN_TOOLCHAIN_INCLUDED)
  return()
endif()
set(CONAN_TOOLCHAIN_INCLUDED TRUE)
```

When minimum version of CMake (3.10) will not be an issue anymore please consider using: https://cmake.org/cmake/help/latest/command/include_guard.html

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).



Discussion:
Hi @mpusz,

~~Thanks a lot for the suggestion, we will take this into account for 2.0 when CMake will be the lowest supported version.~~

EDIT: In fact we can add it now as we in CMakeToolchain we are already adding some 3.15 CMake features. I'll mark this for the next release.


Resolving patch:
diff --git a/conan/tools/cmake/base.py b/conan/tools/cmake/base.py
--- a/conan/tools/cmake/base.py
+++ b/conan/tools/cmake/base.py
@@ -71,10 +71,8 @@ class CMakeToolchainBase(object):
 
         # Avoid including toolchain file several times (bad if appending to variables like
         #   CMAKE_CXX_FLAGS. See https://github.com/android/ndk/issues/323
-        if(CONAN_TOOLCHAIN_INCLUDED)
-          return()
-        endif()
-        set(CONAN_TOOLCHAIN_INCLUDED TRUE)
+        include_guard()
+
 
         {% block before_try_compile %}
             {# build_type (Release, Debug, etc) is only defined for single-config generators #}


Test patch:
Repository: conan-io/conan

Issue:
[bug] Conan client fails when server charset is specified.
I'm experimenting with implementing a conan server. While testing said server I ran into problems because my server fully qualifies the "Content-Type" HTTP header to "application/json; charset=utf-8". The conan client though errors when talking to that server with this error: `Response from remote is not json, but 'application/json; charset=utf-8'.`. JSON content requires utf-8 encoding and charset, which makes the addition in the content-type of the charset optional by the server. But regardless of what the charset is, utf-8 or ascii, clients need to handle there being a charset being specified. Which the conan client doesn't appear to be doing.

### Environment Details (include every applicable attribute)
  * Operating System+version: 5.11.14-1-MANJARO #1 SMP PREEMPT Wed Apr 14 08:25:29 UTC 2021 x86_64 GNU/Linux
  * Compiler+version: NA
  * Conan version: 1.35.1
  * Python version: 3.9.3

[bug] Conan client fails when server charset is specified.
I'm experimenting with implementing a conan server. While testing said server I ran into problems because my server fully qualifies the "Content-Type" HTTP header to "application/json; charset=utf-8". The conan client though errors when talking to that server with this error: `Response from remote is not json, but 'application/json; charset=utf-8'.`. JSON content requires utf-8 encoding and charset, which makes the addition in the content-type of the charset optional by the server. But regardless of what the charset is, utf-8 or ascii, clients need to handle there being a charset being specified. Which the conan client doesn't appear to be doing.

### Environment Details (include every applicable attribute)
  * Operating System+version: 5.11.14-1-MANJARO #1 SMP PREEMPT Wed Apr 14 08:25:29 UTC 2021 x86_64 GNU/Linux
  * Compiler+version: NA
  * Conan version: 1.35.1
  * Python version: 3.9.3



Discussion:
Should be enough to change the `if content_type != 'application/json':` line at `rest_client_common.py`
Hi, I would like to take this on. Can somebody assign me to this issue?
Should be enough to change the `if content_type != 'application/json':` line at `rest_client_common.py`
Hi, I would like to take this on. Can somebody assign me to this issue?

Resolving patch:
diff --git a/conans/client/rest/rest_client_common.py b/conans/client/rest/rest_client_common.py
--- a/conans/client/rest/rest_client_common.py
+++ b/conans/client/rest/rest_client_common.py
@@ -196,7 +196,7 @@ def get_json(self, url, data=None, headers=None):
 
         content = decode_text(response.content)
         content_type = response.headers.get("Content-Type")
-        if content_type != 'application/json':
+        if content_type != 'application/json' and content_type != 'application/json; charset=utf-8':
             raise ConanException("%s\n\nResponse from remote is not json, but '%s'"
                                  % (content, content_type))
 


Test patch:
Repository: conan-io/conan

Issue:
[feature] Lift version limitation for the PyJWT
Currently Conan has version limitation for PyJWT like this:
PyJWT>=1.4.0, <2.0.0

Popular frameworks, like PyGithub, are gradually lifting minimal PyJWT version to the 2.0+, and it becomes problematic to use conan together with the rest of the scripting. Situation is temporary resolvable using virtuenv, but python version switching is yet another dimension for human mistakes, especially for non-experts in python. 

It would be way easier if conan can be installed together with mainstream packages in a typical environment. Can PyJWT version limit be lifted to the 2.0+?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).



Discussion:
Well, it is a major version, so probably requires a bit extra of testing to make sure nothing is broken, not just lifting the version requirements, but might require changes in code (and then the opposite might happen, users stuck with older PyJWT might have incompatibilities).

For example, they are dropping support for Python2 (which we still maintain for Conan 1.X so far),  of the transitive cryptography >= 3, might be an issue.

Lets check it.

Resolving patch:
diff --git a/conans/server/crypto/jwt/jwt_manager.py b/conans/server/crypto/jwt/jwt_manager.py
--- a/conans/server/crypto/jwt/jwt_manager.py
+++ b/conans/server/crypto/jwt/jwt_manager.py
@@ -1,4 +1,5 @@
 from datetime import datetime
+from calendar import timegm
 
 import jwt
 
@@ -20,7 +21,7 @@ def get_token_for(self, profile_fields=None):
         profile_fields = profile_fields or {}
 
         if self.expire_time:
-            profile_fields["exp"] = datetime.utcnow() + self.expire_time
+            profile_fields["exp"] = timegm((datetime.utcnow() + self.expire_time).timetuple())
 
         return jwt.encode(profile_fields, self.secret, algorithm="HS256")
 


Test patch:
diff --git a/conans/test/unittests/server/crypto/jwt_test.py b/conans/test/unittests/server/crypto/jwt_test.py
--- a/conans/test/unittests/server/crypto/jwt_test.py
+++ b/conans/test/unittests/server/crypto/jwt_test.py
@@ -31,7 +31,7 @@ def test_jwt_manager(self):
 
         # Now wait 2 seconds and check if its valid now
         time.sleep(2)
-        self.assertRaises(jwt.ExpiredSignature, manager.get_profile, token)
+        self.assertRaises(jwt.ExpiredSignatureError, manager.get_profile, token)
 
     def test_jwt_credentials_manager(self):
         manager = JWTCredentialsManager(self.secret, self.expire_time)
Repository: conan-io/conan

Issue:
[bug] Incorrect compiler detection for `clang` with `--gcc-toolchain={}` option
When setting e.g.
```
CC="clang-9 --gcc-toolchain=/usr/lib/gcc/x86_64-linux-gnu/9"
CXX="clang++-9 --gcc-toolchain=/usr/lib/gcc/x86_64-linux-gnu/9"
```
Conan will autodetect `gcc` as the compiler because of this line: https://github.com/conan-io/conan/blob/0eea418adf86a93ad3a9547be6e16a3c980ffc4b/conans/client/conf/detect.py#L78


Discussion:
Maybe the `CC` / `CXX` variables should be processed somewhat, to ignore short-form / long-form arguments before checking for `gcc` / `clang` / etc?
Good point, thanks for reporting, indeed seems a bug.

In any case, I would like to recall that for production we recommend using profiles, that will properly define ``settings.compiler=clang``, and there will be no confusion.
Absolutely, and that's what I've changed our system to do (once I worked out how on earth it was getting confused :-)... setting up more specific profiles based on the build targets (previously we **just** set `CC` and `CXX` in the environment for each of the cross-compilers we are using - we will continue doing that of course).

Resolving patch:
diff --git a/conans/client/conf/detect.py b/conans/client/conf/detect.py
--- a/conans/client/conf/detect.py
+++ b/conans/client/conf/detect.py
@@ -107,14 +107,14 @@ def _get_default_compiler(output):
             if compiler:
                 return compiler
         else:
+            if "clang" in command.lower():
+                return _clang_compiler(output, command)
             if "gcc" in command:
                 gcc = _gcc_compiler(output, command)
                 if platform.system() == "Darwin" and gcc is None:
                     output.error("%s detected as a frontend using apple-clang. "
                                  "Compiler not supported" % command)
                 return gcc
-            if "clang" in command.lower():
-                return _clang_compiler(output, command)
             if platform.system() == "SunOS" and command.lower() == "cc":
                 return _sun_cc_compiler(output, command)
         # I am not able to find its version


Test patch:
diff --git a/conans/test/unittests/util/detect_test.py b/conans/test/unittests/util/detect_test.py
--- a/conans/test/unittests/util/detect_test.py
+++ b/conans/test/unittests/util/detect_test.py
@@ -86,3 +86,10 @@ def test_detect_arch(self, machine, expected_arch):
             result = dict(result)
             self.assertEqual(expected_arch, result['arch'])
             self.assertEqual(expected_arch, result['arch_build'])
+
+    @mock.patch("conans.client.conf.detect._clang_compiler", return_value=("clang", "9"))
+    def test_detect_clang_gcc_toolchain(self, _):
+        output = TestBufferConanOutput()
+        with tools.environment_append({"CC": "clang-9 --gcc-toolchain=/usr/lib/gcc/x86_64-linux-gnu/9"}):
+            detect_defaults_settings(output, profile_path="./MyProfile")
+            self.assertIn("CC and CXX: clang-9 --gcc-toolchain", output)
Repository: conan-io/conan

Issue:
Use CMAKE_FIND_ROOT_PATH_MODE_INCLUDE in CMakeToolchain instead of XXX_DIR solution for OSX
> I don't see the new toolchain setting CMAKE_FIND_ROOT_PATH_MODE_INCLUDE, am I missing something? Why this feature in the legacy generators but not the new ones?

`find_package()` doesn't need `CMAKE_FIND_ROOT_PATH_MODE_PACKAGE BOTH` in `CMakeDeps` (see https://github.com/conan-io/conan/issues/9202#issuecomment-878363451, but it could be replaced by `CMAKE_FIND_ROOT_PATH_MODE_PACKAGE BOTH` instead).
`find_library()`, `find_path()` and `find_file()` would also need https://github.com/conan-io/conan/issues/9427, `CMAKE_FIND_ROOT_PATH_MODE_* BOTH` is not sufficient.

_Originally posted by @SpaceIm in https://github.com/conan-io/conan/issues/9437#issuecomment-902808812_


Discussion:

Resolving patch:
diff --git a/conan/tools/cmake/toolchain.py b/conan/tools/cmake/toolchain.py
--- a/conan/tools/cmake/toolchain.py
+++ b/conan/tools/cmake/toolchain.py
@@ -407,9 +407,9 @@ class FindConfigFiles(Block):
 
         # To support cross building to iOS, watchOS and tvOS where CMake looks for config files
         # only in the system frameworks unless you declare the XXX_DIR variables
-        {% for name in find_names %}
-        set({{ name }}_DIR "{{ generators_folder }}")
-        {% endfor %}
+        {% if cross_ios %}
+            set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE BOTH)
+        {% endif %}
         """)
 
     def context(self):
@@ -424,9 +424,7 @@ def context(self):
         android_prefix = "${CMAKE_CURRENT_LIST_DIR}" if os_ == "Android" else None
 
         host_req = self._conanfile.dependencies.host.values()
-        find_names_needed = os_ in ('iOS', "watchOS", "tvOS")
-        find_names = [get_file_name(req)
-                      for req in host_req] if find_names_needed else []
+        cross_ios = os_ in ('iOS', "watchOS", "tvOS")
 
         # Read the buildirs
         build_paths = []
@@ -448,7 +446,7 @@ def context(self):
                 "cmake_prefix_path": "${CMAKE_CURRENT_LIST_DIR} " + build_paths,
                 "cmake_module_path": "${CMAKE_CURRENT_LIST_DIR} " + build_paths,
                 "android_prefix_path": android_prefix,
-                "find_names": find_names,
+                "cross_ios": cross_ios,
                 "generators_folder": "${CMAKE_CURRENT_LIST_DIR}"}
 
 


Test patch:
Repository: conan-io/conan

Issue:
[bug] Wrong parameter name used in find_library() function in cmakedeps_macros.cmake
When using the cmake function find_library() it accepts a parameter named "NAMES" but in cmakedeps_macro.cmake, generated by conan/tools/cmake/cmakedeps/templates/macros.py , the parameter name "NAME" is used by mistake.
See also: https://cmake.org/cmake/help/latest/command/find_library.html

As the NAMES parameter name is kind of optional, it currently works as it is but the find_library() function not only searches for the actual library by its name, but it also looks for a library called NAME.
This can bee seen, when cmake is run with the --debug-find argument.

I will provide a pull request for the fix.





Discussion:

Resolving patch:
diff --git a/conan/tools/cmake/cmakedeps/templates/macros.py b/conan/tools/cmake/cmakedeps/templates/macros.py
--- a/conan/tools/cmake/cmakedeps/templates/macros.py
+++ b/conan/tools/cmake/cmakedeps/templates/macros.py
@@ -36,7 +36,7 @@ def template(self):
            if(APPLE)
                foreach(_FRAMEWORK ${FRAMEWORKS})
                    # https://cmake.org/pipermail/cmake-developers/2017-August/030199.html
-                   find_library(CONAN_FRAMEWORK_${_FRAMEWORK}_FOUND NAME ${_FRAMEWORK} PATHS ${FRAMEWORKS_DIRS} CMAKE_FIND_ROOT_PATH_BOTH)
+                   find_library(CONAN_FRAMEWORK_${_FRAMEWORK}_FOUND NAMES ${_FRAMEWORK} PATHS ${FRAMEWORKS_DIRS} CMAKE_FIND_ROOT_PATH_BOTH)
                    if(CONAN_FRAMEWORK_${_FRAMEWORK}_FOUND)
                        list(APPEND ${FRAMEWORKS_FOUND} ${CONAN_FRAMEWORK_${_FRAMEWORK}_FOUND})
                        message("Framework found! ${FRAMEWORKS_FOUND}")
@@ -51,7 +51,7 @@ def template(self):
            unset(_CONAN_ACTUAL_TARGETS CACHE)
 
            foreach(_LIBRARY_NAME ${libraries})
-               find_library(CONAN_FOUND_LIBRARY NAME ${_LIBRARY_NAME} PATHS ${package_libdir}
+               find_library(CONAN_FOUND_LIBRARY NAMES ${_LIBRARY_NAME} PATHS ${package_libdir}
                             NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
                if(CONAN_FOUND_LIBRARY)
                    conan_message(DEBUG "Library ${_LIBRARY_NAME} found ${CONAN_FOUND_LIBRARY}")


Test patch: