move cloud and test dependencies to "extras"

[cburroughs]

Most downstream users are not on multiple cloud providers, nor do they need to run the tests. Allowing the option to select only what they need simplifies downstream dependency resolutions and prevents conflicts.

(I went with the dev- pattern tests instead of poetry groups, as the CONTRIBUTING instructions pointed towards using pip/requirements and not mandating poetry directly.)

[elongl]

Hi @cburroughs, thanks for opening this PR.
Care to share about the motivation for the change?
I agree that in retrospect, it may have been better to do it this way.
However, I'm concerned that it'll break for users who currently use Elementary.
Would like to understand your use-case a bit better.

[cburroughs]

We use Python (surprise!) and support development on multiple CPU architectures (x86_64, arm64 and Operating Systems (Mac, Linux) and in turn support deployment to Linux on multiple CPU architectures. To interact with the wider Python packaging ecosystem we could:

• (A) Say that everyone needs multiple native code compilers and library headers installed on their workstation, maintaining package lists for both Mac and a hodgepodge of Linux distros.
• (B) Require all 3rd party python packages to be available as wheels, building the missing ones ourselves.

(A) perhaps a more common choice but also an endless series of "IT" style support tarpits while (B) is closer to a problem amendable to software engineering, so we went with (B). We are happy to spin up CI workers and build wheels as needed but in the case of things like test dependencies the idiomatic thing to do is usually not to require them at all. (pytest-parametrization does not provide a wheel if that context was unclear.)

For the cloud provider case, due to the dynamic nature of python packaging pip uses a backtracking resolver with somewhat unpredictable performance characteristics. Having less packages in the transitive graph thus always has marginally benefit and since most companies always use a single cloud provider, that's usually low hanging fruit for limiting scope.

Let me know that helps or if other context would be helpful.

[haritamar]

Hi @cburroughs !
Sorry for the huge delay in our response, and thanks for your explanation above.

I think the points you made make sense. That being said, my primary concern is the same that @elongl brought above - which is breaking setup for existing Elementary users.
We may do this separation eventually with an appropriate heads-up to users, but right now I feel the risk outweighs the benefit.

That being said, for test packages the decision is more straightforward, so I added only this change to a separate PR:
#1537

Closing this one.