irc deps

[hpfn]

Hi,

irc needs:

 jaraco.collections',
'jaraco.text',
'jaraco.itertools',
'jaraco.logging',
'jaraco.functools>=1.5',
'jaraco.stream',

Which are in different repositories. To update irc in Debian I will have to ask ftp-master to include all these new packages, right ?

This split is really necessary ? I am just asking, I am not a programmer.

Regards, Herbert

[jaraco]

Hi Herbert. This functionality started out in a single package called jaraco.utils, but there was a couple of problems with that:

1. The package was a hodgepodge of various functionality, meaning the namesake of the package told very little about what it does, which makes it obscure.
2. Each incremental change to one aspect of the package would cause a release of all aspects of the package, so anything depending on a different aspect would see flux, possibly even have to consider backward-incompatible releases that did not affect it.
3. Sometimes a backward incompatible change would occur and then a new feature would be added in a different aspect, so a user would be required to adopt the backward incompatible change in one aspect to elect the new feature in another aspect.

Honestly, I'd love for all of this functionality to be in a single package. It would simplify the management greatly. However, I'm also trying to follow the common convention that each package should represent a class of functionality or purpose.

A couple of alternative approaches that would help -

• Reduce the dependencies between packages. I suspect some of these packages aren't actually required by irc, but only by other functions in the library on which irc depends.
• Move the functionality on which irc relies to another package. I've [tried doing that with more_itertools (here and here, but I gave up waiting. I also tried contributing compose to the stdlib, but even that small functionality was too controversial to reach a consensus of acceptance. So while I'm open moving this functionality to new homes, I've conceded that I'd rather just maintain the functions where I can manage them.

If you're willing to help with those activities and see them through, I'd be open to the help.

So the short answer is it's not necessary, but it's preferable for these to be in separately maintained. If you can demonstrate another widely accepted technique for solving this issue, I'm open to suggestions.

Thanks.