conan-io/conan-package-tools

Conan Package Tools. Helps with massive package creation and CI integration (Travis CI, Appveyor...)

conan-package-tools's Issues

Error when specifying remote for uploading packages

The documentation states that a remote can be specified, and shows an example on how to do it; however, the example gives me an error:

Traceback (most recent call last):
File "example.py", line 6, in <module>
    builder.upload_packages("mypackage/1.2.3@user/testing", "myconanserverpassword", remote="mycustomserver")
TypeError: upload_packages() got an unexpected keyword argument 'remote'

Example:

from conan.packager import ConanMultiPackager

if __name__ == "__main__":
    builder = ConanMultiPackager([], "user", "testing")
    builder.upload_packages("mypackage/1.2.3@user/testing", "myconanserverpassword", remote="mycustomserver")

Versions:

• conan: 0.7.4
• conan-package-tools: 0.1.2
• Python: 2.7.11

Compressing large files fails on Appveyor before upload

I have a large library (VTK) which I build on Appveyor but in debug it fails to compress all the files due to running out of memory. Can I do something about it? See also the Appveyor-build.

Compressing package...                                                Traceback (most recent call last):
  File "C:\Python27\Scripts\conan-script.py", line 9, in <module>
    load_entry_point('conan==0.8.4', 'console_scripts', 'conan')()
  File "c:\python27\lib\site-packages\conans\conan.py", line 6, in run
    main(sys.argv[1:])
  File "c:\python27\lib\site-packages\conans\client\command.py", line 615, in main
    error = command.run(args)
  File "c:\python27\lib\site-packages\conans\client\command.py", line 529, in run
    method(args[0][1:])
  File "c:\python27\lib\site-packages\conans\client\command.py", line 437, in upload
    args.remote, all_packages=args.all, force=args.force)
  File "c:\python27\lib\site-packages\conans\client\manager.py", line 292, in upload
    uploader.upload_conan(conan_reference, all_packages=all_packages, force=force)
  File "c:\python27\lib\site-packages\conans\client\uploader.py", line 26, in upload_conan
    self.upload_package(PackageReference(conan_ref, package_id), index + 1, total)
  File "c:\python27\lib\site-packages\conans\client\uploader.py", line 35, in upload_package
    self._remote_proxy.upload_package(package_ref)
  File "c:\python27\lib\site-packages\conans\client\proxy.py", line 205, in upload_package
    result = self._remote_manager.upload_package(package_reference, remote)
  File "c:\python27\lib\site-packages\conans\client\remote_manager.py", line 38, in upload_package
    the_files = compress_package_files(the_files)
  File "c:\python27\lib\site-packages\conans\client\remote_manager.py", line 122, in compress_package_files
    return compress_files(files, PACKAGE_TGZ_NAME, excluded=(CONANINFO, CONAN_MANIFEST))
  File "c:\python27\lib\site-packages\conans\client\remote_manager.py", line 144, in compress_files
    addfile(the_file, content, tgz)
  File "c:\python27\lib\site-packages\conans\client\remote_manager.py", line 140, in addfile
    tar.addfile(tarinfo=info, fileobj=string)
  File "c:\python27\lib\tarfile.py", line 2051, in addfile
    copyfileobj(fileobj, self.fileobj, tarinfo.size)
  File "c:\python27\lib\tarfile.py", line 275, in copyfileobj
    dst.write(buf)
  File "c:\python27\lib\gzip.py", line 241, in write
    self.fileobj.write(self.compress.compress(data))
MemoryError: out of memory
Traceback (most recent call last):
  File "build.py", line 8, in <module>
    builder.run()
  File "C:\Python27\lib\site-packages\conan\packager.py", line 244, in run
    self._upload_packages()
  File "C:\Python27\lib\site-packages\conan\packager.py", line 347, in _upload_packages
    raise Exception("Error uploading")
Exception: Error uploading

Decouple the upload user from the recipe user

Now that Bintray is used, the recipe user can be decoupled from the Bintray registered user.

python3 support

The zlib example fails for python3 with

CONAN_USERNAME=ph03 python3 build.py                                                                                                      Mi 05/18/16 21:14
zlib/1.2.8@ph03/testing export: Copied 1 '.cmake' files: FindZLIB.cmake
zlib/1.2.8@ph03/testing export: Copied 1 '.txt' files: CMakeLists.txt
zlib/1.2.8@ph03/testing: The stored package has not changed
zlib/1.2.8@PROJECT
    URL: http://github.com/lasote/conan-zlib
    License: http://www.zlib.net/zlib_license.html
Traceback (most recent call last):
  File "build.py", line 7, in <module>
    builder.run()
  File "/home/janickm/.local/lib/python3.4/site-packages/conan/packager.py", line 244, in run
    self._pack()
  File "/home/janickm/.local/lib/python3.4/site-packages/conan/packager.py", line 267, in _pack
    self._execute_build(build)
  File "/home/janickm/.local/lib/python3.4/site-packages/conan/packager.py", line 376, in _execute_build
    self._execute_test(None, settings, options)
  File "/home/janickm/.local/lib/python3.4/site-packages/conan/packager.py", line 81, in _execute_test
    conan_compiler, conan_compiler_version = self.conan_compiler_info()
  File "/home/janickm/.local/lib/python3.4/site-packages/conan/packager.py", line 388, in conan_compiler_info
    from ConfigParser import ConfigParser
ImportError: No module named 'ConfigParser'

whereas with python2 it works great

env CONAN_USERNAME=ph03 python build.py                                                                                                   Mi 05/18/16 21:14
zlib/1.2.8@ph03/testing export: Copied 1 '.cmake' files: FindZLIB.cmake
zlib/1.2.8@ph03/testing export: Copied 1 '.txt' files: CMakeLists.txt
zlib/1.2.8@ph03/testing: The stored package has not changed
zlib/1.2.8@PROJECT
    URL: http://github.com/lasote/conan-zlib
    License: http://www.zlib.net/zlib_license.html

############## CONAN PACKAGE TOOLS ######################

DEBUG: - Skipped build, compiler mismatch: {'compiler.version': '4.6', 'arch': 'x86', 'build_type': 'Debug', 'compiler': 'gcc'}

#########################################################


############## CONAN PACKAGE TOOLS ######################

DEBUG: - Skipped build, compiler mismatch: {'compiler.version': '4.6', 'arch': 'x86', 'build_type': 'Release', 'compiler': 'gcc'}

#########################################################

Is it a problem on my side, or should I be able to run the tool with python3 as well?

Verbose option for print build list

Conan Package Tools introduced the print build list that helps to identify all builds to be performed.

# packager.py:225
print("Page       : ", curpage)
print("Builds list:")
for p in builds_in_current_page: print(list(p._asdict().items()))

Today I'm working with Gcc and Clang, so, I got a bunch of builds in my CI log for each job. It's not a problem, but could be selected by verbose option:

# packager.py:205
def run_builds(self, curpage=None, total_pages=None, verbose=False):
  ...
    if verbose:
        print("Page       : ", curpage)
        print("Builds list:")
        for p in builds_in_current_page: print(list(p._asdict().items()))

Another approach, could be using python logging, putting this message on DEBUG level.

Appveyor integration broken since yesterday

https://ci.appveyor.com/project/nunojpg/conan-botan/build/job/3ckemv2apg4if2rn

    Running setup.py install for conan-package-tools: finished with status 'done'
Successfully installed PyJWT-1.4.2 PyYAML-3.12 asn1crypto-0.22.0 astroid-1.4.9 backports.functools-lru-cache-1.3 bottle-0.12.13 cffi-1.10.0 colorama-0.3.9 conan-0.22.3 conan-package-tools-0.3.2 configparser-3.5.0 cryptography-1.8.1 distro-1.0.4 enum34-1.1.6 fasteners-0.14.1 future-0.16.0 idna-2.5 ipaddress-1.0.18 isort-4.2.5 lazy-object-proxy-1.3.1 mccabe-0.6.1 monotonic-1.3 node-semver-0.1.1 packaging-16.8 patch-1.16 pluginbase-0.5 pyOpenSSL-17.0.0 pycparser-2.17 pylint-1.6.5 pyparsing-2.2.0 requests-2.14.1 six-1.10.0 wrapt-1.10.10
conan user
Traceback (most recent call last):
  File "C:\Python27\Scripts\conan-script.py", line 6, in <module>
    from pkg_resources import load_entry_point
  File "c:\python27\lib\site-packages\pkg_resources\__init__.py", line 3017, in <module>
    @_call_aside
  File "c:\python27\lib\site-packages\pkg_resources\__init__.py", line 3003, in _call_aside
    f(*args, **kwargs)
  File "c:\python27\lib\site-packages\pkg_resources\__init__.py", line 3030, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "c:\python27\lib\site-packages\pkg_resources\__init__.py", line 661, in _build_master
    return cls._build_from_requirements(__requires__)
  File "c:\python27\lib\site-packages\pkg_resources\__init__.py", line 674, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "c:\python27\lib\site-packages\pkg_resources\__init__.py", line 853, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'requests<2.14.0,>=2.7.0' distribution was not found and is required by conan
Command exited with code 1

os setting is missing

Hi,

I would expect the ConanMultiPackager's builds to have the os setting since this setting is available in most other contexts.
I currently want to disable Linux 32 bit builds like this:

builder = ConanMultiPackager()
builder.add_common_builds(...)
builder.builds = [
    [settings, options]
    for settings, options in builder.builds
    if not (settings["os"] == "Linux" and settings["arch"] == "x86")
]

However it is obvious from the source that os is never defined:

Traceback (most recent call last):
  File "build.py", line 11, in <module>
    if not (settings["os"] == "Linux" and settings["arch"] == "x86")
KeyError: 'os'

I suppose os may also be valuable in the future if cross compilation is supported.

Temporary directory "~/" created on build

Hi!

Conan package tools 0.4.31 creates a directory "~" in current project directory, when the build starts.

Steps to reproduce:

1. Start a docker container
   $ docker run --rm -ti lasote/conangcc63

2. Update Conan and Package Tools
   $ sudo pip install -U conan conan_package_tools

3. Create a empty project
   $ conan new -s -t foobar/0.1.0@qux/baz

4. Create default build.py

from conan.packager import ConanMultiPackager

if __name__ == "__main__":
    builder = ConanMultiPackager(username="qux")
    builder.add_common_builds()
    builder.run()

5. Just run it
   $ python build.py

As result, conan + conan_package_tools will produce a entry tested package.
However, a list command will show:

conan@e93746325111:~/$ ls
build.py  conanfile.py  src  test_package  ~

And finally we have:
$ file \~/.conan/conan.conf

I didn't see that behavior before.

Cannot install conan-package-tools on lasote/conangcc53

Last docker image does not contain openssl so cryphography cannot be installed.

See the build https://travis-ci.org/theirix/conan-jsoncpp/jobs/205219355
Also reproducible by launching sudo pip install conan_package_tools --upgrade with the latest lasote/conangcc53 image.

Installing collected packages: conan-package-tools, idna, pyasn1, enum34, ipaddress, pycparser, cffi, cryptography, pyOpenSSL
Running setup.py install for conan-package-tools ... done
Running setup.py install for pycparser ... done
Running setup.py install for cryptography ... error
Complete output from command /usr/bin/python -u -c "import setuptools, tokenize;file='/tmp/pip-build-OvhSK2/cryptography/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record /tmp/pip-M7vs4Z-record/install-record.txt --single-version-externally-managed --compile:
running install
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/cryptography
copying src/cryptography/fernet.py -> build/lib.linux-x86_64-2.7/cryptography
copying src/cryptography/init.py -> build/lib.linux-x86_64-2.7/cryptography
copying src/cryptography/about.py -> build/lib.linux-x86_64-2.7/cryptography
copying src/cryptography/exceptions.py -> build/lib.linux-x86_64-2.7/cryptography
copying src/cryptography/utils.py -> build/lib.linux-x86_64-2.7/cryptography
creating build/lib.linux-x86_64-2.7/cryptography/x509
copying src/cryptography/x509/extensions.py -> build/lib.linux-x86_64-2.7/cryptography/x509
copying src/cryptography/x509/base.py -> build/lib.linux-x86_64-2.7/cryptography/x509
copying src/cryptography/x509/init.py -> build/lib.linux-x86_64-2.7/cryptography/x509
copying src/cryptography/x509/oid.py -> build/lib.linux-x86_64-2.7/cryptography/x509
copying src/cryptography/x509/general_name.py -> build/lib.linux-x86_64-2.7/cryptography/x509
copying src/cryptography/x509/name.py -> build/lib.linux-x86_64-2.7/cryptography/x509
creating build/lib.linux-x86_64-2.7/cryptography/hazmat
copying src/cryptography/hazmat/init.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat
creating build/lib.linux-x86_64-2.7/cryptography/hazmat/backends
copying src/cryptography/hazmat/backends/init.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends
copying src/cryptography/hazmat/backends/interfaces.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends
copying src/cryptography/hazmat/backends/multibackend.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends
creating build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
copying src/cryptography/hazmat/primitives/constant_time.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
copying src/cryptography/hazmat/primitives/serialization.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
copying src/cryptography/hazmat/primitives/init.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
copying src/cryptography/hazmat/primitives/hmac.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
copying src/cryptography/hazmat/primitives/keywrap.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
copying src/cryptography/hazmat/primitives/padding.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
copying src/cryptography/hazmat/primitives/cmac.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
copying src/cryptography/hazmat/primitives/hashes.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
creating build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings
copying src/cryptography/hazmat/bindings/init.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings
creating build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
copying src/cryptography/hazmat/backends/openssl/encode_asn1.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
copying src/cryptography/hazmat/backends/openssl/rsa.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
copying src/cryptography/hazmat/backends/openssl/init.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
copying src/cryptography/hazmat/backends/openssl/dsa.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
copying src/cryptography/hazmat/backends/openssl/hmac.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
copying src/cryptography/hazmat/backends/openssl/ec.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
copying src/cryptography/hazmat/backends/openssl/decode_asn1.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
copying src/cryptography/hazmat/backends/openssl/dh.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
copying src/cryptography/hazmat/backends/openssl/backend.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
copying src/cryptography/hazmat/backends/openssl/cmac.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
copying src/cryptography/hazmat/backends/openssl/hashes.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
copying src/cryptography/hazmat/backends/openssl/utils.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
copying src/cryptography/hazmat/backends/openssl/ciphers.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
copying src/cryptography/hazmat/backends/openssl/x509.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/openssl
creating build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/commoncrypto
copying src/cryptography/hazmat/backends/commoncrypto/init.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/commoncrypto
copying src/cryptography/hazmat/backends/commoncrypto/hmac.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/commoncrypto
copying src/cryptography/hazmat/backends/commoncrypto/backend.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/commoncrypto
copying src/cryptography/hazmat/backends/commoncrypto/hashes.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/commoncrypto
copying src/cryptography/hazmat/backends/commoncrypto/ciphers.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/commoncrypto
creating build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/ciphers
copying src/cryptography/hazmat/primitives/ciphers/base.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/ciphers
copying src/cryptography/hazmat/primitives/ciphers/init.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/ciphers
copying src/cryptography/hazmat/primitives/ciphers/algorithms.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/ciphers
copying src/cryptography/hazmat/primitives/ciphers/modes.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/ciphers
creating build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/kdf
copying src/cryptography/hazmat/primitives/kdf/kbkdf.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/kdf
copying src/cryptography/hazmat/primitives/kdf/hkdf.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/kdf
copying src/cryptography/hazmat/primitives/kdf/init.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/kdf
copying src/cryptography/hazmat/primitives/kdf/pbkdf2.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/kdf
copying src/cryptography/hazmat/primitives/kdf/scrypt.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/kdf
copying src/cryptography/hazmat/primitives/kdf/concatkdf.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/kdf
copying src/cryptography/hazmat/primitives/kdf/x963kdf.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/kdf
creating build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/twofactor
copying src/cryptography/hazmat/primitives/twofactor/init.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/twofactor
copying src/cryptography/hazmat/primitives/twofactor/totp.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/twofactor
copying src/cryptography/hazmat/primitives/twofactor/hotp.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/twofactor
copying src/cryptography/hazmat/primitives/twofactor/utils.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/twofactor
creating build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/interfaces
copying src/cryptography/hazmat/primitives/interfaces/init.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/interfaces
creating build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/asymmetric
copying src/cryptography/hazmat/primitives/asymmetric/rsa.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/asymmetric
copying src/cryptography/hazmat/primitives/asymmetric/init.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/asymmetric
copying src/cryptography/hazmat/primitives/asymmetric/dsa.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/asymmetric
copying src/cryptography/hazmat/primitives/asymmetric/ec.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/asymmetric
copying src/cryptography/hazmat/primitives/asymmetric/padding.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/asymmetric
copying src/cryptography/hazmat/primitives/asymmetric/dh.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/asymmetric
copying src/cryptography/hazmat/primitives/asymmetric/utils.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/asymmetric
creating build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/openssl
copying src/cryptography/hazmat/bindings/openssl/init.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/openssl
copying src/cryptography/hazmat/bindings/openssl/_conditional.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/openssl
copying src/cryptography/hazmat/bindings/openssl/binding.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/openssl
creating build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/commoncrypto
copying src/cryptography/hazmat/bindings/commoncrypto/init.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/commoncrypto
copying src/cryptography/hazmat/bindings/commoncrypto/binding.py -> build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/commoncrypto
running egg_info
writing requirements to src/cryptography.egg-info/requires.txt
writing src/cryptography.egg-info/PKG-INFO
writing top-level names to src/cryptography.egg-info/top_level.txt
writing dependency_links to src/cryptography.egg-info/dependency_links.txt
writing entry points to src/cryptography.egg-info/entry_points.txt
reading manifest file 'src/cryptography.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
no previously-included directories found matching 'docs/_build'
warning: no previously-included files matching '*' found under directory 'vectors'
writing manifest file 'src/cryptography.egg-info/SOURCES.txt'
running build_ext
generating cffi module 'build/temp.linux-x86_64-2.7/_padding.c'
creating build/temp.linux-x86_64-2.7
generating cffi module 'build/temp.linux-x86_64-2.7/_constant_time.c'
generating cffi module 'build/temp.linux-x86_64-2.7/_openssl.c'
building '_openssl' extension
creating build/temp.linux-x86_64-2.7/build
creating build/temp.linux-x86_64-2.7/build/temp.linux-x86_64-2.7
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c build/temp.linux-x86_64-2.7/_openssl.c -o build/temp.linux-x86_64-2.7/build/temp.linux-x86_64-2.7/_openssl.o
build/temp.linux-x86_64-2.7/_openssl.c:434:30: fatal error: openssl/opensslv.h: No such file or directory
compilation terminated.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

----------------------------------------

Command "/usr/bin/python -u -c "import setuptools, tokenize;file='/tmp/pip-build-OvhSK2/cryptography/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record /tmp/pip-M7vs4Z-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-OvhSK2/cryptography/

Python3 doesn't work on OSX

https://travis-ci.org/nunojpg/conan-botan/jobs/232949741

Traceback (most recent call last):
  File "/Users/travis/.pyenv/versions/3.6.1/envs/conan/lib/python3.6/site-packages/pkg_resources/__init__.py", line 659, in _build_master
    ws.require(__requires__)
  File "/Users/travis/.pyenv/versions/3.6.1/envs/conan/lib/python3.6/site-packages/pkg_resources/__init__.py", line 967, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/Users/travis/.pyenv/versions/3.6.1/envs/conan/lib/python3.6/site-packages/pkg_resources/__init__.py", line 858, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (pyOpenSSL 17.0.0 (/Users/travis/.pyenv/versions/3.6.1/envs/conan/lib/python3.6/site-packages), Requirement.parse('pyOpenSSL<16.1.0,>=16.0.0'), {'conan'})

Tested it failing for Python 3.5 and 3.6.

In Linux it works fine.

LD does not search lib32 in docker images

It would appear that ld is not searching the correct paths when building for 32 bit linux. See the build log below

https://travis-ci.org/Outurnate/conan-FLAC/jobs/187063573

AppVeyor integration working?

I'm getting this failure: https://ci.appveyor.com/project/nunojpg/conan-restbed/build/1.0.3

WARN: Remotes registry file missing, creating default one in C:\Users\appveyor.conan\registry.txt
Current 'conan.io' user: None (anonymous)
C:\Python27-x64\python build.py
Traceback (most recent call last):
File "build.py", line 1, in
from conan.packager import ConanMultiPackager
ImportError: No module named conan.packager
Command exited with code 1

I've searched for any recent builds succeeding on AppVeyor, but don't know of any repositories with CI going.

Can't build on non-default version of gcc

We're trying to build a package with gcc 4.9. The system has versions 4.8, 4.8, 6.3 (default).

if __name__ == "__main__":
    builder = ConanMultiPackager(
    reference="switcher/0.4",
    upload=True,
    remote="barbarian")
    builder.add({"os": "Linux", "compiler": "gcc", "compiler.libcxx": "libstdc++", "compiler.version": "4.9", "build_type": "Debug", "arch": "x86"})
    builder.add({"os": "Linux", "compiler": "gcc", "compiler.libcxx": "libstdc++", "compiler.version": "4.9", "build_type": "Debug", "arch": "x86_64"})
    builder.run()

It seems to be the first time you've ran conan
Auto detecting your dev setup to initialize conan.conf
Found gcc 6.3
Default conan.conf settings
    os=Linux
    arch=x86_64
    compiler=gcc
    compiler.version=6.3
    compiler.libcxx=libstdc++
    build_type=Release
*** You can change them in ~/.conan/conan.conf ***
*** Or override with -s compiler='other' -s ...s***


WARN: Conanfile doesn't have 'url'.
It is recommended to add it as attribute
WARN: Conanfile doesn't have 'license'.
It is recommended to add it as attribute
WARN: Conanfile doesn't have 'description'.
It is recommended to add it as attribute
switcher/0.4@paulius/switcher_program: A new conanfile.py version was exported
switcher/0.4@paulius/switcher_program: Folder: /home/parallels/.conan/data/switcher/0.4/paulius/switcher_program/export
PROJECT: WARN: config() has been deprecated. Use config_options and configure
switcher/0.4@PROJECT
WARN: Remotes registry file missing, creating default one in /home/parallels/.conan/registry.txt

############## CONAN PACKAGE TOOLS ######################

DEBUG: - Skipped build, compiler mismatch: {'os': 'Linux', 'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86', 'build_type': 'Debug', 'compiler': 'gcc'}

#########################################################


############## CONAN PACKAGE TOOLS ######################

DEBUG: - Skipped build, compiler mismatch: {'os': 'Linux', 'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Debug', 'compiler': 'gcc'}

#########################################################

It looks like conan found the default compiler and is sticking with it. How can we make it recognise other versions? We could define the CXX variable or change the settings, but we're going to be doing multi-compiler builds pretty soon, and ConanMultiPackager seems like our best bet here.

Pages behaviour

It is somehow not specified on the documentation how the builds are split by pages.

I've tested it and it seems that page N gets the builds with array index i mod N == 0, that is for example for 4 pages:

builder.builds[0] - > Page 1
builder.builds[1] - > Page 2
builder.builds[2] - > Page 3
builder.builds[3] - > Page 4
builder.builds[4] - > Page 1
builder.builds[5] - > Page 2

Please confirm and I can pull request a docs clarification.

Also, is there a way to have any control over this? For example, if I have 2 pages, I might want to split the builds in Page 1 for x86 and Page 2 for x86_64 so they take about the same time, as I also might want to keep variations of Debug or Shared in the same page, to reuse builds that just do different packaging.

Would I have to construct my builds array with x86 on even indexes and x86_64 on odd indexes?

Thanks,
Nuno

Easier way to use pages?

My Qt package is very long to build and I need to be sure only one build is executed in one CI executor. This can be achieve using pages but it can be quite complicated to evaluate the number of pages to set and which executor will build what.
For example, to build with 2 versions of msvc, in debug and release, I have to configure appveyor as follow:

        - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2015
          CONAN_VISUAL_VERSIONS: 12
          CONAN_TOTAL_PAGES: 4
          CONAN_CURRENT_PAGE: 1
        - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2015
          CONAN_VISUAL_VERSIONS: 12
          CONAN_TOTAL_PAGES: 4
          CONAN_CURRENT_PAGE: 2
        - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2015
          CONAN_VISUAL_VERSIONS: 12
          CONAN_TOTAL_PAGES: 4
          CONAN_CURRENT_PAGE: 3
        - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2015
          CONAN_VISUAL_VERSIONS: 12
          CONAN_TOTAL_PAGES: 4
          CONAN_CURRENT_PAGE: 4
        - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2015
          CONAN_VISUAL_VERSIONS: 14
          CONAN_TOTAL_PAGES: 4
          CONAN_CURRENT_PAGE: 1
        - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2015
          CONAN_VISUAL_VERSIONS: 14
          CONAN_TOTAL_PAGES: 4
          CONAN_CURRENT_PAGE: 2
        - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2015
          CONAN_VISUAL_VERSIONS: 14
          CONAN_TOTAL_PAGES: 4
          CONAN_CURRENT_PAGE: 3
        - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2015
          CONAN_VISUAL_VERSIONS: 14
          CONAN_TOTAL_PAGES: 4
          CONAN_CURRENT_PAGE: 4

But to reach this result I have to understand how the package tools work internally and next time I will read the script, there is a high chance I will need time to understand what is done. And if I want to add mingw configurations, it becomes even more unclear.

Is there an easier way to work with pages? Or maybe is there a way to directly say what should be build by the executor?

Add support for XCode8

XCode 8 was released in 9/13/2016.
It would be great if conan-packge-tools could support it.

https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html

MinGW builds not working with appveyor

When running a mingw build in appveyor, I get the following error:
ERROR: Conanfile: 'settings.compiler.libcxx' value not defined

When conan user is called, conan set the default settings for Visual Studio and do not set the libcxx setting. Then when the conan-package-tools starts the mingw build, it does not provide the libcxx setting neither.

Is there a way for me to set this settings in the appveyor configuration?

A build log is available here: https://ci.appveyor.com/project/osechet/conan-icu/build/1.0-6/job/x5efdfydi1pq1q06

builder.builds = filtered_builds not filtering?

I'm using a script similiar to the example to filter x86 builds, but the x86 builds were still present, so I added some debug prints:

    builder = ConanMultiPackager(username="nunojpg")
    builder.add_common_builds(shared_option_name="restbed:shared", pure_c=False)
    filtered_builds = []
    for settings, options, env_vars, build_requires in builder.builds:
        if settings["arch"] != "x86":
            filtered_builds.append([settings, dict(options.items() + [('restbed:ssl', False)]), env_vars, build_requires])
            filtered_builds.append([settings, dict(options.items() + [('restbed:ssl', True)]), env_vars, build_requires])
    print "filtered_builds="
    print filtered_builds
    builder.builds = filtered_builds
    print "builder.builds="
    print builder.builds
    builder.run()

The output is like this:

filtered_builds=
[[{'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Debug', 'compiler': 'gcc'}, {'restbed:shared': True, 'restbed:ssl': False}, {}, {}], [{'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Debug', 'compiler': 'gcc'}, {'restbed:shared': True, 'restbed:ssl': True}, {}, {}], [{'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Release', 'compiler': 'gcc'}, {'restbed:shared': True, 'restbed:ssl': False}, {}, {}], [{'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Release', 'compiler': 'gcc'}, {'restbed:shared': True, 'restbed:ssl': True}, {}, {}], [{'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Debug', 'compiler': 'gcc'}, {'restbed:shared': False, 'restbed:ssl': False}, {}, {}], [{'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Debug', 'compiler': 'gcc'}, {'restbed:shared': False, 'restbed:ssl': True}, {}, {}], [{'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Release', 'compiler': 'gcc'}, {'restbed:shared': False, 'restbed:ssl': False}, {}, {}], [{'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Release', 'compiler': 'gcc'}, {'restbed:shared': False, 'restbed:ssl': True}, {}, {}]]
builder.builds=
[BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86', 'build_type': 'Debug', 'compiler': 'gcc'}, options={'restbed:shared': True}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86', 'build_type': 'Release', 'compiler': 'gcc'}, options={'restbed:shared': True}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86', 'build_type': 'Debug', 'compiler': 'gcc'}, options={'restbed:shared': False}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86', 'build_type': 'Release', 'compiler': 'gcc'}, options={'restbed:shared': False}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Debug', 'compiler': 'gcc'}, options={'restbed:shared': True}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Release', 'compiler': 'gcc'}, options={'restbed:shared': True}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Debug', 'compiler': 'gcc'}, options={'restbed:shared': False}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Release', 'compiler': 'gcc'}, options={'restbed:shared': False}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Debug', 'compiler': 'gcc'}, options={'restbed:shared': True, 'restbed:ssl': False}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Debug', 'compiler': 'gcc'}, options={'restbed:shared': True, 'restbed:ssl': True}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Release', 'compiler': 'gcc'}, options={'restbed:shared': True, 'restbed:ssl': False}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Release', 'compiler': 'gcc'}, options={'restbed:shared': True, 'restbed:ssl': True}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Debug', 'compiler': 'gcc'}, options={'restbed:shared': False, 'restbed:ssl': False}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Debug', 'compiler': 'gcc'}, options={'restbed:shared': False, 'restbed:ssl': True}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Release', 'compiler': 'gcc'}, options={'restbed:shared': False, 'restbed:ssl': False}, env_vars={}, build_requires={}), BuildConf(settings={'compiler.version': '4.9', 'compiler.libcxx': 'libstdc++', 'arch': 'x86_64', 'build_type': 'Release', 'compiler': 'gcc'}, options={'restbed:shared': False, 'restbed:ssl': True}, env_vars={}, build_requires={})]

So the filtered_builds array doesn't have any x86 as expected, but the builder.builds has.

Am I doing something wrong?

Actual execution at: https://travis-ci.org/nunojpg/conan-restbed/jobs/224929589

Channel & upload configuration in appveyor

Hello,

I have a couple of questions with regard to the following commit of my package:

https://github.com/coding3d/conan-ogg/tree/a7d075f530520c28544a17eb39405681d4e37e01

The commit has produced the following build on appveyor:

https://ci.appveyor.com/project/coding3d/conan-ogg/build/1.0.11

My questions may be due to my own misunderstanding but I am mentioning them here, in case they are actually issues that have to do with the package tools:

• Should this build have led to an upload to conan.io, given the fact that I have set CONAN_UPLOAD to 0 in appveyor.yml? Does CONAN_UPLOAD control whether or not the packages will be uploaded, or does it do something else?
• Since I have set CONAN_CHANNEL to "ci" in appveyor.yml, why is the channel of uploaded packages "stable"? In general, can we control what the channel of uploaded packages is? (If the "stable" channel is a conan.io best practice, it sounds good, but it's still good to know).

Thanks!

Add support for linux clang

Old version of CMake in the images in the Docker Hub

The following images in the Docker Hub have CMake 3.4 instead of CMake 3.7 which is expected according to Dockerfile

• lasote/conangcc62
• lasote/conangcc49

Please also add links to Dockerfile to Docker Hub image's pages.

MinGW build fails in Appveyor

This MinGW build failed in Appveyor but I don't know why. Everything works fine until the package creation. Then it complains about virtual environment. I have never seen this problem until now. I guess it's related to to the fact conan-package-tools uses mingw_installer (in a virtual environment) but I don't know what to do to fix it.
Can you help me?

Plan for Profile breaking change in develop

Current conan develop branch has changed, so it produces a failure in conan-package-tools:

File "C:\Users\memsharded\conanws\conan-package-tools\conan\packager.py", line 335, in _get_profile
    return Profile.loads(tmp % (settings, options, env_vars, br_lines))
AttributeError: type object 'Profile' has no attribute 'loads'

Remember to update it for next release

Update readme

Hi,

afaik the command test was changed from "test" to "test-package"?

Greets

Enhancement: Add CONAN_UPLOAD_RETRY

Add CONAN_UPLOAD_RETRY configuration to deal with ECONNRESET failures.

Add lasote/conanclang39 capability

More flexible handling of `upload_repo`

I have some problems with running the new upload handling in ConanMultiPackager using our private conan registry.

First problem, I already have a conan remote entry with the same address as the one specified in the upload parameter. Which then gives the following error:

ERROR: Remote 'foo' already exists with same URL

Maybe the upload parameter should be able to specify an existing remote entry if the build environment already has this set up?

If I remove this entry this entry before running the builder I can upload the package. But, if I run the build script a second time the packager.py tries to add the upload_repoagain, even though it already exist.

ERROR: Remote 'upload_repo' already exists in remotes (use update to modify)

I do not see where this is removed from the list of remotes?

add_common_builds for Windows assumes mingw

After upgrading to 0.2.20, I'm getting:

Traceback (most recent call last):
  File "build.py", line 18, in <module>
     builder.add_common_builds(pure_c=False)
   File "C:\Users\Jenkins\AppData\Roaming\Python\Python27\site-packages\conan\packager.py", line 124, in add_common_builds
     if self.mingw_builds(pure_c):
   File "C:\Users\Jenkins\AppData\Roaming\Python\Python27\site-packages\conan\packager.py", line 95, in mingw_builds
    version, arch, exception, thread = config
    ValueError: need more than 1 value to unpack

Looks like mingw_builds needs to check if mingw_configurations is empty?

        for config in self.mingw_configurations:
            version, arch, exception, thread = config

Travis GCC 5.2, 5.3 builds not scheduled correctly

In my package I set up two pages in the Travis-config so that for every gcc version there is one build job for debug and one for release builds (I am just building for x86_64). This works fine for all gcc versions except 5.2 and 5.3 where each of the two Travis builds builds debug *and release and therefore hit the build timeout limit.

Is there anything I am doing wrong? Thanks a lot!

Libraries incompatibility when running build.py on linux

I've created a package for dlib and it worked in appveyor, but on local linux and travis I get an error at the test_package step

home/conan/.conan/data/dlib/19.1.0/.../lib/libdlib.so when searching for -ldlib
/usr/bin/ld: skipping incompatible /home/conan/.conan/data/dlib/19.1.0/.../lib/libdlib.a when searching for -ldlib

I've checked on local linux and the library and its dependencies are build with the same arch. Runnig just test_package works fine. What can be the problem?

Add support for custom options combinations

tools.vcvars_command empty when running with package tools

My package build fails in appveyor because tools.vcvars_command() returns an empty string. I found the problem occurs when the build is started with the build.py script. On my machine, if I build the package normally (with test_package for example), everything is fine. If I call python build.py, the build fails with the same error as in appveyor:

&& was unexpected at this time.

A failing build is accessible here: https://ci.appveyor.com/project/osechet/conan-qt-base/build/job/mvkk4vc67rfsarow

Better control on visual studio default builds

When using visual studio builds and default builds it is not possible to have Visual Studio 2010 64Bits builds and also one cannot select which runtime to compile, merge requests #5 and #6 resolve this without changing the way it work before.

Appveyor freezes and times out?

This is more a question about the use of the tools with appveyor rather than an issue with the tools themselves. I have this build:

https://ci.appveyor.com/project/coding3d/conan-ogg

It freezes after setting up conaninfo.txt and then times out. Is this a known issue with appveyor or may there be something that I am doing wrong? It has happened to me before and then it just stopped happening without me doing anything special, at least as far as I understood.

Wrong password when using special characters

Short explanation:
When I try to upload some package, by conan_package_tools, I receive:

ERROR: Wrong user or password.

Full explanation:
My user and password work well when I execute by conan's client:

$ conan user -r conan.io -p '<password-with-special-characters>' uilianries
Change 'conan.io' user from None (anonymous) to uilianries

However, when I use conan package tools, the authentication fails:

CONAN_USERNAME=uilianries CONAN_CHANNEL=ci CONAN_REFERENCE=libusb/1.0.21 CONAN_PASSWORD='<password-with-special-characters>' CONAN_UPLOAD=1 python build.py

At the end, all my builds pass, but the upload fails:

############## CONAN PACKAGE TOOLS ######################

INFO: ******** RUNNING UPLOAD COMMAND **********
conan upload libusb/1.0.21@uilianries/ci --all --force

#########################################################

ERROR: Wrong user or password. [Remote: conan.io]
Traceback (most recent call last):
File "build.py", line 13, in
builder.run()
File "/usr/local/lib/python2.7/dist-packages/conan/packager.py", line 273, in run
self._upload_packages()
File "/usr/local/lib/python2.7/dist-packages/conan/packager.py", line 375, in _upload_packages
raise Exception("Error with user credentials")
Exception: Error with user credentials

I tried escape the special characters by '\' (e.g. '1234\&\$foobar'), but didn't work.

I read packager.py and I just found a replace for double quotes. Another point is that, the password is forwarded to conan user command, by python os.system.

To simplify the analysis, I wrote the follow code:

from os import getenv
from os import system
 
if __name__ == "__main__":
    env = getenv("CONAN_PASSWORD")
    env =  env.replace('"', '\\"')
    system("echo %s" % env)
    system("conan user -c")
    system("conan user -r conan.io -p %s uilianries" % env)

This piece works well when I export my password in quotes.

I'm using conan at version 0.20.2 and conan_package_tools 0.2.35 (both are latest).

I have no more ideas how to use the automatic upload with my password.

Why DLLs are never built with static runtime?

In file conan/packager.py, method _add_visual_builds():

        if shared_option_name:
            if "MT" in self.visual_runtimes:
                sets.append([{"build_type": "Release", "compiler.runtime": "MT"},
                             {shared_option_name: False}])
            if "MTd" in self.visual_runtimes:
                sets.append([{"build_type": "Debug", "compiler.runtime": "MTd"},
                             {shared_option_name: False}])

Why DLLs are never built with static runtime? It is very useful and I can't find any pros for the current behavior.

Priority of visual_versions ConanMultiPackager's parameter vs CONAN_VISUAL_VERSIONS

Disclaimer: I am a newbie using Conan and GitHub, so probably what I am proposing here is completely wrong, or the style is not correct... Sorry for that.

I am creating a package for a library that, under Windows, is only compilable using Visual Studio 2013 (12) and 2015 (14). I am trying to show this restriction in the build.py file, so looks like this:

from conan.packager import ConanMultiPackager
if __name__ == "__main__":
    builder = ConanMultiPackager(username="demo")
    builder.add_common_builds(visual_versions = ["12", "14"])
    builder.run()

In my machine, I only have VS 2013 installed so, in order to build the packages, I tried this:

set CONAN_VISUAL_VERSIONS="12" 
python build.py

However, the script tried to build the package using both VS 2013 and 2015 which caused a build error. Checking the code of packager.py I found:

if visual_versions is not None:
    self.visual_versions = visual_versions
else:
    env_visual_versions = list(filter(None, os.getenv("CONAN_VISUAL_VERSIONS", "").split(",")))
    self.visual_versions = env_visual_versions or self.default_visual_versions

That is, the ConanMultiPackager's parameter has priority over the environment variable. However, in my opinion, the environment variable should have a higher priority, as it would allow to cover cases like this (a machine with only a VS environment installed) without having to modify the script.

Thanks in advance.

Automatic test requires does not work with CI

Official documentation and conan new -t suggest using a conanfile in a test package without requires directive. I tried to use this.

Travis uses CONAN_USERNAME, CONAN_PASSWORD and maybe CONAN_REFERENCE and others that should be passed to the conan-package-tools and then to the conan API. But it says "Please specify user and channel" when running on Travis, running build.py. Running test_package with a reference on command line works fine. Running test_package without a reference obviously fails.

I tried to debug a problem - user variables is lost between c-p-t and conan API.

conan (0.25.1)
conan-package-tools (0.4.35)

Unable to locate "vcvarsall.bat" during Visual Studio 2017 builds

When attempting to build with Visual Studio 2017, the following error is produced:

The system cannot find the path specified.
Error while executing:
call "%vs150comntools%../../VC/Auxiliary/Build/vcvarsall.bat" amd64 && conan test_package . -s arch="x86_64" -s build_type="Release" -s compiler="Visual Studio" -s compiler.runtime="MT" -s compiler.version="15" -o thelib:shared="False"

I noted that there was a commit to add support for it:
c4cace8

But Microsoft has removed the %vsXXXcomntools% variables starting with VS2017 and forward:
https://blogs.msdn.microsoft.com/vcblog/2017/03/06/finding-the-visual-c-compiler-tools-in-visual-studio-2017/

Currently we are working around this by manually creating a vs150comntools variable.

Add Bamboo CI

I'd like to see bamboo get recognized the same way as appveyor and travis. Proposition lies in PR #11

Regression on 0.3.1: ValueError: too many values to unpack

This build now fails:

https://travis-ci.org/nunojpg/conan-restbed/jobs/222866566

+python build.py
############## CONAN PACKAGE TOOLS ######################
WARNING: Redefined channel by CI branch matching with 'master', setting CONAN_CHANNEL to 'stable'
#########################################################
Traceback (most recent call last):
File "build.py", line 7, in
for settings, options in builder.builds:
ValueError: too many values to unpack
The command "./.travis/run.sh" exited with 1.

Stable channel support for Gitlab

Hi!

At packager.py:470, we have:

def _get_channel(self, default_channel, stable_channel)

This function filter the CI runner by environment variable, but Gitlab is not listed. As result, CONAN_STABLE_BRANCH_PATTERN doesn't work at Gitlab Runner.

To support this new feature, you could use Gitlab Variables.

I think that, this piece solves the case:

gitlab = os.getenv("GITLAB_CI" , False)  # Mark that job is executed in GitLab CI environment
gitlab_branch = os.getenv("CI_BUILD_REF_NAME", False)  # The branch or tag name for which project is built

Saludos.

Stable username option

Hi!

The conventional behavior using conan is, each user provides some channel with it packages, for example, I created libusb package at conan.io, so, who wants this package, will look at uilianries/stable. Okay, this works and everybody goes happy to home.

However, if you use conan at your company and want to create some main stable channel, this approach will not fit very well. For example, the developers Foo, Qux and Baz, use the same package in some project, but no one wants to keep searching who is the maintainer of package and where is the real stable package, so, the solution is create a main user name: Company. After this point, all developers know the stable channel will be at Company/version. But, I new problem comes, who is Company user maintainer and who submits in it channel? Any one could submit, since the package was validate (build, tests ...).

The Conan package tools switch to stable channel when it found some pattern in branch name. But, consider the situation where my package will be the main package for all developers, so I'll need bring this package to Company user. To do this, I need to change the user name and password to upload at stable channel. This works, but is a quite manual.

To turn this process more automatic, the user name could be switched by stable pattern, some like this:

# packager.py:490

if channel:
    self.logger.warning("Redefined channel by CI branch matching with '%s', "
"setting CONAN_CHANNEL to '%s'" % (pattern, channel))
	self.username = getenv("CONAN_STABLE_USERNAME", self.username)
	self.password = getenv("CONAN_STABLE_PASSWORD", self.password)

This piece will change the current user name to a stable user name, when the stable channel is used. If a stable user name was not defined, so, the current user name is maintained as before. The same behavior is applied to password.

The stable switch for user name allows an automatic switch not just for channel. So, when I need some package, by default, I'll search at Company user, instead to ask who is the real maintainer.

Update recommended travis.yml

README.md suggests a slightly outdated versions of xcode.
Travis stopped supporting xcode7.1 and xcode 6.2 recently so they are silently dispatched to the xcode 7.3 instead:

This job was configured to run on an OS X image that was retired on November 28, 2016. It was routed to our Xcode 7.3.1 infrastructure.

Xcode 8.1 and 8.2 should be added.

There is a more generic question about a lifecycle of package's .travis.yml - how can it be updated? Should it be updated automatically or should the repository owner be notified about change?

Cannot upload to specified remote

when using a different remote, only the conan upload call had the remote added, we need the conan user call to have it too. Merge Request #4 resolves this

build_policy missunderstanding

Hi!

I'm building a package (here) that download the sources from a git repo. I want to maintain a version, master, that always grab the last revision from that repository. I supposed that this will be the behaviour of build_policy='always', the client will get the sources and compile them each time conan install is invoked... but

ERROR: Conanfile has build_policy='always', no packages can be uploaded
Traceback (most recent call last):
  File "build.py", line 16, in <module>
    builder.run()
  File "C:\Python27-x64\lib\site-packages\conan\packager.py", line 261, in run
    self._upload_packages()
  File "C:\Python27-x64\lib\site-packages\conan\packager.py", line 367, in _upload_packages
    raise Exception("Error uploading")
Exception: Error uploading
Command exited with code 1

It's ok, it has no sense to upload the binaries, but I want to upload the recipe... is this behaviour possible?

Thanks!

Windows builds end to C:\

Hi

I'm using conan-package-tools in Windows and when I run the python build.py command, all the packages are built in C:.conan folder instead of C:\Users\user.conan.
There's an interesting effect too: in C:\Users\user.conan\MyPackage\ there are .conan_link files pointing to the C:.conan folder.

How can I force to build the packages in user folders instead of on C: root folder?

Wildcard upload requires confirmation

Conan will ask for confirmation (yes/no) if the upload reference is a pattern.
The packager should probably pass --confirm to conan upload since it's purpose is mostly for CI/automation. Without --confirm my CI job creates an infinite large log when it hangs at:

Are you sure you want to upload '...'? (yes/no): ERROR:  is not a valid answer
Are you sure you want to upload '...'? (yes/no): ERROR:  is not a valid answer
...

Problem when user's password contains spaces

When a package is about to be uploaded, the user's password is not quoted when running conan user. This is a problem if the password contains spaces.

Allow for custom package root path

Currently, ConanMultiPackager._docker_pack method has path to "project" directory hard-coded:

command = "sudo docker run --rm -v %s:/home/conan/project -v " \
          "~/.conan/data:/home/conan/.conan/data -it %s %s /bin/sh -c \"" \
          "cd project && sudo pip install conan_package_tools --upgrade %s && " \
          "conan_json_packager\"" % (curdir, env_vars, image_name, specific_conan_package)

I would like to be able to use custom path (e.g. subdirectory of "project"), maybe via another CONAN_... environment variable. This would allow for multiple packages to be stored within a single repository.