Re: [Distutils] YAGNI extras and tests_require
Oops, I forgot to copy the list on my first respose.
On Sun, 2006-10-22 at 14:45 -0400, Jim Fulton wrote:
Matt Good wrote:
On Sun, 2006-10-22 at 13:52 -0400, Jim Fulton wrote:
I'd like to call "Ya aint gonna need it" on the extras feature of setuptools.
As far as I can tell, extras are just a way to avoid fine-grained packages. Is this benefit worth the complexity? I don't think so. It violates "There's Only One Way To Do It" and increases the complexity of setuptools.
Setuptools is wonderful but it is complex. I think it would be helpful to make it simpler and I really don't see a need for extras.
Well, I've found them to be useful with entry points in Trac plugins. For example the SpamFilter plugin provides several spam filtering methods, not all of which will be needed by every user. There's an IP blacklist filter that requires DNSPython. By declaring the entry point for the blacklist module with an extra for DNSPython the module will only load if that requirement is available.
Why not just distribute the IP blacklist filter as a separate package?
I don't think it's uncommon for packages to have optional features that require additional dependencies, and extras provide an easy way to declare those dependencies. Sure, sometimes these features could be broken out into a separate package, but in the cases where I've used extras making additional packages would be the more complex solution.
How more complex? You would simply have had more packages? Is that really more complex that extras?
Yes. An extra is simply a line or two in setup.py. A separate package means another branch in SVN, more releases to make, upload to the Cheeseshop, more files for users to download, and unneeded duplication between the original and new package. This seems like an awful lot of additional work just to justify removing a feature from setuptools.
Is it advantagous enough to violate TWOOWTDI?
How does it violate that? There's *always* more than one way, but there should be one clear "right way", and I think extras *is* that way. There are clearly times when the right thing is to create a new separate package, but I think that new package should have sufficient substance and be decoupled from the original to justify distributing it separately.
Is it really worth this extra complexity in setuptools?
Well, since Phillip is maintaining it I guess it's his decision. I think it's feature that's useful to developers, so I'm in favor of keeping it.
Matt Good wrote:
Oops, I forgot to copy the list on my first respose.
On Sun, 2006-10-22 at 14:45 -0400, Jim Fulton wrote:
Matt Good wrote:
On Sun, 2006-10-22 at 13:52 -0400, Jim Fulton wrote:
I'd like to call "Ya aint gonna need it" on the extras feature of setuptools.
As far as I can tell, extras are just a way to avoid fine-grained packages. Is this benefit worth the complexity? I don't think so. It violates "There's Only One Way To Do It" and increases the complexity of setuptools.
Setuptools is wonderful but it is complex. I think it would be helpful to make it simpler and I really don't see a need for extras.
Well, I've found them to be useful with entry points in Trac plugins. For example the SpamFilter plugin provides several spam filtering methods, not all of which will be needed by every user. There's an IP blacklist filter that requires DNSPython. By declaring the entry point for the blacklist module with an extra for DNSPython the module will only load if that requirement is available.
Why not just distribute the IP blacklist filter as a separate package?
I don't think it's uncommon for packages to have optional features that require additional dependencies, and extras provide an easy way to declare those dependencies. Sure, sometimes these features could be broken out into a separate package, but in the cases where I've used extras making additional packages would be the more complex solution.
How more complex? You would simply have had more packages? Is that really more complex that extras?
Yes. An extra is simply a line or two in setup.py. A separate package means another branch in SVN,
Not necessarily. You could manage multiple related packages as a single SVN project. I do.
more releases to make, upload to the Cheeseshop,
True.
more files for users to download,
If the downloads are automated, does this make a difference?
and unneeded duplication between the original and new package.
Why duplication? Likely, one of the packages would simply depend on the other.
This seems like an awful lot of additional work just to justify removing a feature from setuptools.
I think the extra work is just making the extra releases, at least assuming automated downloads.
Is it advantagous enough to violate TWOOWTDI?
How does it violate that? There's *always* more than one way, but there should be one clear "right way", and I think extras *is* that way.
There don't have to be multiple ways. I also don't see extras as being clearly superior, but we disagree.
Jim
participants (2)
-
Jim Fulton -
Matt Good