Conan: Feature: Provide deploy-file functionality similar to that of Maven

[ikotlova]

Could you, please provide deploy-file (or upload-file) functionality similar to the Maven's?
http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

Deploy-file would support C/C++ binary file parameters like: OS, architecture, bitness, build-type. As well as some custom parameters configurable with Conan.

This feature would greatly facilitate managing C/C++ built/archived artifacts.

Thanks much!

[lasote]

Hi @ikotlova, I would need more information about this feature. How could it help to manage the built artifacts? Please elaborate the use case flow.

[ikotlova]

The use case would be to connect multiple builds that use different build workflow (Conan and non-Conan); and builds that may be spread out but are 'connected' to each other via some Artifactory resource where they publish their artifacts. For instance, one non-Conan build would create custom OpenSSL set of libraries for several platforms/architectures; it would publish/deploy/upload those libraries to the Artifactory's Conan repository as multiple .zip files, one for each platform/architecture. The next build would download/install them depending on the platform and build next level of a product.

In the other words: this feature would help tremendously in connecting non-Conan build with another Conan/non-Conan build.

It would be very similar to Maven's deploy-file API, with the difference of being able to specify some additional standard and custom parameters. Standard/custom parameters may be build type (debug/release), os (Linux, Solaris, AIX, Windows, ...), bitness (32/64), architecture (intel, sparc, ...).

[memsharded]

Approved, lets try to make it into 0.22.

[memsharded]

After my first analysis, my proposal would be of the form of a new binary command:

$ conan new MyPkg/0.1@user/channel --binaries # basic option will create bare package recipe
# Have the chance to edit the recipe for extra options or behavior, shouldnt be necessary for many cases
$ conan export user/channel
$ conan binary MyPkg/0.1@user/channel --path=path/to/mybins -s compiler=gcc -s compiler.version=...
# or with profiles
$ conan binary MyPkg/0.1@user/channel -pr=myprofile  # use the cwd as default paths to the binaries

All of these commands are local, after that, the conan upload and conan install are as usual

If we wanted to add binaries from another platform, for an existing package, we could do:

$ conan install MyPkg/0.1@user/channel --recipe
$ conan binary MyPkg/0.1@user/channel -pr=otherprofile

I think this is a clear, intuitive and complete approach to the issue. Not as convenient as one single line automagic command, but that is a "porcelain" that can be added later if necessary, now it is important to define a complete, configurable and robust process

[lasote]

I don't like the binary name. It doesn't explain what's happening. You are creating (binary) packages from local files directly. pack ?

[memsharded]

There is already the package command, I am trying to avoid it and similar names. export_package?

[lasote]

bundle?

[ikotlova]

What about 'package-file'?
This would imply 'just the file itself, no other packaging instructions'.

Thanks much!

[memsharded]

It doesn't package just a file, even if of course you can package just a file, but in many cases packages will be composed by more than one file, so at least it should be plural: package_files. It is not a bad name, I like bundle because it is short, but it is true that package_files is much more evident of the command intent.

Maybe an option to conan package?:

$ conan package MyPkg/0.1@user/channel --files=path/to/files -pr=myprofile
# or --files="."

@lasote?

[lasote]

It has been released in conan 0.22.0 and documented here:
http://conanio.readthedocs.io/en/latest/packaging/existing_binaries.html

Please, report with any problem or feedback. Thanks

[sheeeng]

The documentation link to this feature was changed.
http://conanio.readthedocs.io/en/latest/packaging/existing_binaries.html