Re: 📦 Advice on packaging azure-cli

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 25. 05. 21 14:29, Major Hayden wrote:
👋🏻 Hello there,

I'm eager to package Azure's CLI tools for Fedora that would allow users to manage their Microsoft Azure cloud infrastructure. This would help with CI/CD, information security, monitoring, and of course, deployments.

However, these cloud tools are a bit tricky to package. There are a few python components in the main repository[0] that make up the CLI itself:

   azure-cli
   azure-cli-core
   azure-cli-telemetry

Those seem fairly straightforward, but things get complicated because those three depend on *plenty* of little SDK components from another repository[1]. That repository contains over 220 SDK components that all release independently from the same git repository. They also have dependencies on some other bits of python that are already packaged for Fedora, such as cffi, cryptography, and PyYAML.

To make things a bit more complicated, the core CLI tools have strict dependencies on specific versions of the SDK components. For example:

     'azure-mgmt-datamigration~=4.1.0',
     'azure-mgmt-deploymentmanager~=0.2.0',
     'azure-mgmt-devtestlabs~=4.0',
     'azure-mgmt-dns~=8.0.0',

At first glance, that doesn't seem too bad since the versions of the core CLI tools and SDK versions move in tandem in the repositories. SDK components are constantly moving forward, but the CLI releases are tied to specific SDK component versions which do not change after release.

The dependency tree is fairly long[2], but it's also fairly standard between most of the SDKs.

I have several questions here:

   1) Should I make separate Fedora packages/specs for each CLI
      component and the SDK components? The SDK components look
      nearly identical from a packaging standpoint (no executables
      there, just libraries in each). If so, that would be about
      80-100 packages to make and maintain.

The culprit of trying to maintain them in one component is that they are released independently. Maintaining various subpackages with different versions and release cycles from the same spec file is a huge PITA.

However, so is maintaining 100 packages. There is no clear win. I'd personally rather maintain the 100 packages with automatically generated build dependencies, but I would not say it is a *should*.

Have a look at https://src.fedoraproject.org/rpms/pyproject-rpm-macros

   2) Should I 'vendor' the SDK components into a single package and
      set it as a dependency of the core CLI tools?

I'd say doing that is pretty much the same amount of work as maintaining a single-spec multi-package beast mentioned above, but less user friendly.

   3) Should I dynamically generate spec files for the SDK components
      based on the requirements from the main CLI tools?

The spec files should be almost identical with just the name/summary/description/version changing, so I'd say this is a way to go.

   4) Am I making this much, much more difficult than it really is? 🤦🏻‍♂️

It is already difficult.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux