ZCML implementations: where should they go
Hi there, We've recently had some discussions on where to place the implementation of various ZCML directives. This post is to try to summarize the issue and analyze the options we have. Right now ZCML directives are implemented in packages that contain other implementation. For example, zope.component implements various ZCML directives, and zope.security implements some more. In the case of zope.component, a special [zcml] extras dependency section is declared. If the ZCML dependencies are asked for, using zope.component will suddenly pull in a much larger list of dependencies than the original zope.component dependency list. The ZCML directives are component-related, but do offer extra options that need bits from the wider Zope 3 framework, such as the security infrastructure. In the case of zope.security, this isn't the case. As far as I can see, it doesn't declare any dependency beyond zope.configuration to allow it to implement its ZCML directives. The dependency situation for the ZCML implementations in zope.component doesn't appear ideal. It was therefore proposed to move the ZCML implementations to another package. This could be a new package, or it could be created. Following up on that, it was considered we should move *all* directives from the packages that implement them now into special packages. This would allow some packages to lose the dependency on zope.configuration, which is a relatively minor gain. We have several ways to go: a) continue with the current extra dependencies situation like in zope.component, and in fact clean up other packages that define ZCML to declare ZCML extra dependencies. b) pull out all ZCML implementations from where they are now and put them in special ZCML implementation packages. We could for instance have zcml.component, or zope.component_zcml, or zope.configuration.component. We had a bit of a side-tracked discussion about naming and namespace packages here. c) pull out only those ZCML implementations that cause extra dependencies beyond zope.configuration. So, we extract the bits of zope.component into a new package, but we don't extract bits from zope.security. I personally don't like extras. I think the ideal situation would be if packages had *no* extras at all (even test extras), as it complicates reasoning about the dependency structure. I think with improved structuring of the dependency graph, a package should have enough in its implementation dependencies to implement its tests. We've already experienced some of that last week at the sprint. For ZCML, with improved structuring of the dependency graph a package should only need zope.configuration as an extra package to implement ZCML. For that reason, a) is not really an option for me. That leaves b) and c). I think for now we should go with c), as it's the smallest step forward that will help clean up things. That is, we either find and appropriate package that makes sense for the ZCML implementations in zope.component, or we create a new package. Of course if we create a new package we still have a naming discussion ahead and I risk sparking another naming discussion (as it's easy to have an opinion about names). So, what do people think about option c)? Regards, Martijn
Martijn Faassen wrote:
We've recently had some discussions on where to place the implementation of various ZCML directives. This post is to try to summarize the issue and analyze the options we have.
Thanks for summarizing this!
We have several ways to go:
a) continue with the current extra dependencies situation like in zope.component, and in fact clean up other packages that define ZCML to declare ZCML extra dependencies.
-1 from me. I see the test extra as a necessary evil to get us moving with the lessened-dependency project. Multiple extras will just cause an increasing number of combinations of packages which aren't tested anymore. If you have a extra in your package, it should be possible to move the added functionality from the extra into a package that depends on the original package.
b) pull out all ZCML implementations from where they are now and put them in special ZCML implementation packages. We could for instance have zcml.component, or zope.component_zcml, or zope.configuration.component. We had a bit of a side-tracked discussion about naming and namespace packages here.
c) pull out only those ZCML implementations that cause extra dependencies beyond zope.configuration. So, we extract the bits of zope.component into a new package, but we don't extract bits from zope.security.
+0 Seems reasonable to me. Hanno
Hey Hanno, Thanks for your feedback! Hanno Schlichting wrote:
Martijn Faassen wrote: [snip]
a) continue with the current extra dependencies situation like in zope.component, and in fact clean up other packages that define ZCML to declare ZCML extra dependencies.
-1 from me. [snip motivation I agree with]
options b and c:
+0 Seems reasonable to me.
Anything you'd actually be +1 on? :) Regards, Martijn
Martijn Faassen wrote:
Hanno Schlichting wrote:
Martijn Faassen wrote: [snip]
a) continue with the current extra dependencies situation like in zope.component, and in fact clean up other packages that define ZCML to declare ZCML extra dependencies. -1 from me. [snip motivation I agree with]
options b and c:
+0 Seems reasonable to me.
Anything you'd actually be +1 on? :)
I haven't figured out yet, what I'd like to do with ZCML and zope.configuration in general. It seems to me that ZCML is right now too tightly bound to application configuration. Zope2 and Five need different action handlers and this will continue to be the case for the next years and possibly forever. Grok has different needs for the configuration part of your application. repoze.bfg takes yet another approach. Once we define a Grok-like API for Plone we will probably end up with yet some other kind of different semantics. My gut feeling is that the best long term answer would be to figure out how to split zope.configuration and ZCML kind of in the middle. What parts of application configuration are actually reusable and which are not. How does application configuration and system configuration like paste.ini and zope.conf fir together? Just trying to push out ZCML in itself seems better than having it stay in, but not what I'd consider to be a good long term answer. Hanno
Hanno Schlichting wrote: [snip]
Anything you'd actually be +1 on? :)
I haven't figured out yet, what I'd like to do with ZCML and zope.configuration in general. It seems to me that ZCML is right now too tightly bound to application configuration. Zope2 and Five need different action handlers and this will continue to be the case for the next years and possibly forever.
I thought significant process was made on the ability to reuse more handlers now that Zope 2 has got __parent__ support. Not enough?
Grok has different needs for the configuration part of your application.
Grok does reuse some actions defined for the use of ZCML actually, though sometimes we do introduce new ones.
repoze.bfg takes yet another approach.
I'm sure there are new ZCML directives it introduces, but it also forked the current ZCML directives that are in zope.component for basic component registration, to reduce its dependencies. Perhaps that fork can be undone if we improve the way we break things down (to anticipate what you're saying below).
Once we define a Grok-like API for Plone we will probably end up with yet some other kind of different semantics.
If you define altogether new actions that are Plone specific there might not be too big of a problem in overlap there.
My gut feeling is that the best long term answer would be to figure out how to split zope.configuration and ZCML kind of in the middle. What parts of application configuration are actually reusable and which are not. How does application configuration and system configuration like paste.ini and zope.conf fir together?
Just trying to push out ZCML in itself seems better than having it stay in, but not what I'd consider to be a good long term answer.
I'd consider it at least a necessary step towards a long term answer, so you should be +1 for step one. :) Another step would be to start taking a look at refactoring the actions to increase reuse. I think refactoring the actions can be driven by the needs of the code that uses it. If Zope 2 developers say: hey, we could *almost* use this action if it only didn't do this, we could use that to split the action into two parts so that the main part can be reused. The Grok developers and Repoze developers should look for similar opportunities. It might be that some actions very similar to the ones the repoze fork now uses will make it back into zope.component, but that the extended ones that Zope 3 requires should be extracted. Note that I don't mind much that zope.configuration has intrinsic support for ZCML (besides the general action-based configuration system). Grok needs that support anyway, and so will any system that at least wants to support packages that load their configuration using ZCML. Regards, Martijn
Martijn Faassen wrote:
Hanno Schlichting wrote: [snip]
Anything you'd actually be +1 on? :) I haven't figured out yet, what I'd like to do with ZCML and zope.configuration in general. It seems to me that ZCML is right now too tightly bound to application configuration. Zope2 and Five need different action handlers and this will continue to be the case for the next years and possibly forever.
I thought significant process was made on the ability to reuse more handlers now that Zope 2 has got __parent__ support. Not enough?
Some progress has been made. But some of the actions actually do have a different semantic in Five, like all the resource things. The URL scheme they produce is different for example. Some others will need to adhere to different security needs or use different base classes for the automagically inserted classes. Last time I looked there was no clear next step that would need to be taken to remove more custom handlers.
Just trying to push out ZCML in itself seems better than having it stay in, but not what I'd consider to be a good long term answer.
I'd consider it at least a necessary step towards a long term answer, so you should be +1 for step one. :)
I'm +0, since I don't yet know, where the journey will take us and if this is a step into the right direction. If others drive this forward, I'm fine with it. I'm just not going to put lots of my time into it just yet. Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Hanno Schlichting wrote: [snip]
Anything you'd actually be +1 on? :) I haven't figured out yet, what I'd like to do with ZCML and zope.configuration in general. It seems to me that ZCML is right now too tightly bound to application configuration. Zope2 and Five need different action handlers and this will continue to be the case for the next years and possibly forever.
I thought significant process was made on the ability to reuse more handlers now that Zope 2 has got __parent__ support. Not enough?
Grok has different needs for the configuration part of your application.
Grok does reuse some actions defined for the use of ZCML actually, though sometimes we do introduce new ones.
repoze.bfg takes yet another approach.
I'm sure there are new ZCML directives it introduces, but it also forked the current ZCML directives that are in zope.component for basic component registration, to reduce its dependencies. Perhaps that fork can be undone if we improve the way we break things down (to anticipate what you're saying below).
The fork is not merely to reduce dependencies: BFG also wants to eliminate the requirement that there be "one global component registry to rule them all," which is pretty deeply embedded in zope.component. Breaking that assumption allows multiple BFG apps to run in the same process, with incompatible components registered, without any chance that they will step on each other's toes.
Once we define a Grok-like API for Plone we will probably end up with yet some other kind of different semantics.
If you define altogether new actions that are Plone specific there might not be too big of a problem in overlap there.
My gut feeling is that the best long term answer would be to figure out how to split zope.configuration and ZCML kind of in the middle. What parts of application configuration are actually reusable and which are not.
"Reusable configuration" is a bit of an oxymoron: if everybody *must* use the configuration, then it isn't configuration at all, but software. I think, however, that this discussion is about where to put the "meta" bits (the parts which actually implement ZCML directives), rather than rehashing the library vs. application problem (where to put the configuration).
How does application configuration and system configuration like paste.ini and zope.conf fir together?
Just trying to push out ZCML in itself seems better than having it stay in, but not what I'd consider to be a good long term answer.
I'd consider it at least a necessary step towards a long term answer, so you should be +1 for step one. :)
Another step would be to start taking a look at refactoring the actions to increase reuse. I think refactoring the actions can be driven by the needs of the code that uses it. If Zope 2 developers say: hey, we could *almost* use this action if it only didn't do this, we could use that to split the action into two parts so that the main part can be reused. The Grok developers and Repoze developers should look for similar opportunities.
It might be that some actions very similar to the ones the repoze fork now uses will make it back into zope.component, but that the extended ones that Zope 3 requires should be extracted.
Note that I don't mind much that zope.configuration has intrinsic support for ZCML (besides the general action-based configuration system). Grok needs that support anyway, and so will any system that at least wants to support packages that load their configuration using ZCML.
I would argue that putting any ZCML-related implementation in a separate package from the zope.component core would be a win, at least from the perspective of clarity and dependencies. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJkE3v+gerLs4ltQ4RAvbxAJ40EfLHA+l/8ixXFmuVQJO9e15QYQCcDazx rGxL8+ZQpfxnAPbGLV1O0GM= =mutG -----END PGP SIGNATURE-----
Hey, Tres Seaver wrote: [snip]
repoze.bfg takes yet another approach. I'm sure there are new ZCML directives it introduces, but it also forked the current ZCML directives that are in zope.component for basic component registration, to reduce its dependencies. Perhaps that fork can be undone if we improve the way we break things down (to anticipate what you're saying below).
The fork is not merely to reduce dependencies: BFG also wants to eliminate the requirement that there be "one global component registry to rule them all," which is pretty deeply embedded in zope.component. Breaking that assumption allows multiple BFG apps to run in the same process, with incompatible components registered, without any chance that they will step on each other's toes.
Cool, I hadn't realized that. I think it would be useful to fold that support into the Zope framework itself too. [snip]
"Reusable configuration" is a bit of an oxymoron: if everybody *must* use the configuration, then it isn't configuration at all, but software.
I think, however, that this discussion is about where to put the "meta" bits (the parts which actually implement ZCML directives), rather than rehashing the library vs. application problem (where to put the configuration).
Yes. My interpretation of what Hanno said was that he was talking about reusing the implementation of configuration. I.e. repoze.zcml might define an action that zope.componentconf might use in the implementation of its own actions. Anyway, no matter what Hanno said, I think that is an interesting area to explore. Grok and Five both want to reuse as much of the underlying action implementation in the Zope framework as possible. [snip]
I would argue that putting any ZCML-related implementation in a separate package from the zope.component core would be a win, at least from the perspective of clarity and dependencies.
Agreed. It might be that the core implementations of actions a-la repoze.zcml could be moved into zope.component. repoze.zcml could then become a smaller package that simply registers the directives themselves for these actions. We could then have something that builds on this (and zope.security) to implement the directives that zope.component now implements. Regards, Martijn
Hello, Monday, February 9, 2009, 5:58:34 PM, you wrote:
The fork is not merely to reduce dependencies: BFG also wants to eliminate the requirement that there be "one global component registry to rule them all," which is pretty deeply embedded in zope.component. Breaking that assumption allows multiple BFG apps to run in the same process, with incompatible components registered, without any chance that they will step on each other's toes.
There is something similar, z3c.baseregistry, or not? -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: True love is when your heart and your mind are saying the same thing. - Leanna L. Bartram
Hi Martijn, Without comparison otherwise, you may find my thoughts here useful: http://www.martinaspeli.net/articles/granting-plone-an-api
a) continue with the current extra dependencies situation like in zope.component, and in fact clean up other packages that define ZCML to declare ZCML extra dependencies.
-0.5 I think this will require more discipline than usual, and it'll a pain to test how a package behaves both with and without extras.
b) pull out all ZCML implementations from where they are now and put them in special ZCML implementation packages. We could for instance have zcml.component, or zope.component_zcml, or zope.configuration.component. We had a bit of a side-tracked discussion about naming and namespace packages here.
+0.5 I would suggest we have a namespace package and a naming convention to allow this to grow over time. For example, we could have a zope.zcml.* naming convention, so you'd have zope.zcml.component, zope.zcml.content and so on. Having a single package could become painful when people start refactoring and branching, as you could easily get into situations where it becomes hard to upgrade or manage releases.
c) pull out only those ZCML implementations that cause extra dependencies beyond zope.configuration. So, we extract the bits of zope.component into a new package, but we don't extract bits from zope.security.
-0.5 This policy sounds confusing to me, which means that people will probably screw it up. :)
For that reason, a) is not really an option for me. That leaves b) and c). I think for now we should go with c), as it's the smallest step forward that will help clean up things. That is, we either find and appropriate package that makes sense for the ZCML implementations in zope.component, or we create a new package. Of course if we create a new package we still have a naming discussion ahead and I risk sparking another naming discussion (as it's easy to have an opinion about names).
So, what do people think about option c)?
I see no problem with starting with zope.component, but I'd consider both naming conventions and package structure conventions in a wider context before making the leap with zope.component, to reduce the chance of inconsistencies in the future. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote: [snip]
I see no problem with starting with zope.component, but I'd consider both naming conventions and package structure conventions in a wider context before making the leap with zope.component, to reduce the chance of inconsistencies in the future.
We already had a rather fruitless naming discussion, which is why I'm still in favor of option c) (avoiding the creation of new packages where possible). Option b) risks us creating a lot more small packages that we'll have to manage, and ultimately I'd like to *reduce* the amount of packages in the Zope framework. And as I already said, I like small steps. I think we should adhere to the principle that a package should have the code and dependencies to run its tests, with typically no test extras needed therefore, and no dependencies just to support testing. I think we should also have the principle that code to configure a concepts introduced by a package (such as component configuration, security configuration) should be in that package, if at least this doesn't expand dependency requirements. I saw that this principle seemed to work fairly well when we moved ZCML directives out of both zope.app.security and zope.app.component into zope.security: these directives were mostly (though not entirely) about security anyway, and the move didn't introduce new dependencies. Regards, Martijn
Martijn Faassen wrote at 2009-2-7 17:07 +0100:
... I personally don't like extras. I think the ideal situation would be if packages had *no* extras at all (even test extras)
I do not follow your objections against "extra". Each individual extra "XXXX:extra" is equivalent to a separate package "XXXX_extra" depending on "XXXX" (and potentially many other things). The extras are just a convenient way to avoid cluttering the distribution namespace. That said, I like a).
as it complicates reasoning about the dependency structure. I think with improved structuring of the dependency graph, a package should have enough in its implementation dependencies to implement its tests.
But then many packages are likely to depend on "zope.testing" and maybe even "buildout". Would we really want such dependencies? -- Dieter
2009/2/8 Dieter Maurer <dieter@handshake.de>:
Each individual extra "XXXX:extra" is equivalent to a separate package "XXXX_extra" depending on "XXXX" (and potentially many other things). The extras are just a convenient way to avoid cluttering the distribution namespace.
That said, I like a).
+1 -- WBR, Dan Korostelev
Previously Martijn Faassen wrote:
We have several ways to go:
a) continue with the current extra dependencies situation like in zope.component, and in fact clean up other packages that define ZCML to declare ZCML extra dependencies.
+1 I'ld rather not see a whole slew of extra packagse appear. I also wonder how the extra number of packages and increasing size of sys.path influence performance and restrictions on environments like GAE.
b) pull out all ZCML implementations from where they are now and put them in special ZCML implementation packages. We could for instance have zcml.component, or zope.component_zcml, or zope.configuration.component. We had a bit of a side-tracked discussion about naming and namespace packages here.
+0.5 It solves the problem in a consistent way
c) pull out only those ZCML implementations that cause extra dependencies beyond zope.configuration. So, we extract the bits of zope.component into a new package, but we don't extract bits from zope.security.
+0.1 This introduces inconsistencies that might be confusing. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
I'ld rather not see a whole slew of extra packagse appear. I also wonder how the extra number of packages and increasing size of sys.path influence performance and restrictions on environments like GAE.
For environments like GAE you don't want setuptools and its magic to be part of your application. This is were repackaging your entire app into one zipped egg or some other flat structure comes in handy. Setuptools and eggs are a distribution format from my point of view. They are certainly not the best way to deploy your applications. The growing sys.path is affecting performance to some degree in all deployment environments. Hanno
Hanno Schlichting wrote at 2009-2-8 14:14 +0100:
Wichert Akkerman wrote:
I'ld rather not see a whole slew of extra packagse appear. I also wonder how the extra number of packages and increasing size of sys.path influence performance and restrictions on environments like GAE.
For environments like GAE you don't want setuptools and its magic to be part of your application. This is were repackaging your entire app into one zipped egg or some other flat structure comes in handy.
But you can do that (packaging everything into a single zip) at "home" -- and can interpret "extra"s there (without a need to have "setuptools" to call in your deployment environment.
Setuptools and eggs are a distribution format from my point of view. They are certainly not the best way to deploy your applications. The growing sys.path is affecting performance to some degree in all deployment environments.
I think your single zip would not mind whether it were build from a flat egg structure or from one with ":extra".... -- Dieter
Hanno Schlichting wrote:
Wichert Akkerman wrote:
I'ld rather not see a whole slew of extra packagse appear. I also wonder how the extra number of packages and increasing size of sys.path influence performance and restrictions on environments like GAE.
For environments like GAE you don't want setuptools and its magic to be part of your application. This is were repackaging your entire app into one zipped egg or some other flat structure comes in handy.
Setuptools and eggs are a distribution format from my point of view. They are certainly not the best way to deploy your applications. The growing sys.path is affecting performance to some degree in all deployment environments.
Well, zc.buildout ought to be able to eliminate this concern for GAE deployment. I haven't tried the recipe below, but it certainly seems like the right idea. http://pypi.python.org/pypi/rod.recipe.appengine Shane
On Feb 7, 2009, at 11:07 AM, Martijn Faassen wrote:
Hi there,
We've recently had some discussions on where to place the implementation of various ZCML directives. This post is to try to summarize the issue and analyze the options we have.
Right now ZCML directives are implemented in packages that contain other implementation. For example, zope.component implements various ZCML directives, and zope.security implements some more.
In the case of zope.component, a special [zcml] extras dependency section is declared. If the ZCML dependencies are asked for, using zope.component will suddenly pull in a much larger list of dependencies than the original zope.component dependency list. The ZCML directives are component-related, but do offer extra options that need bits from the wider Zope 3 framework, such as the security infrastructure.
In the case of zope.security, this isn't the case. As far as I can see, it doesn't declare any dependency beyond zope.configuration to allow it to implement its ZCML directives.
The dependency situation for the ZCML implementations in zope.component doesn't appear ideal. It was therefore proposed to move the ZCML implementations to another package. This could be a new package, or it could be created.
Following up on that, it was considered we should move *all* directives from the packages that implement them now into special packages. This would allow some packages to lose the dependency on zope.configuration, which is a relatively minor gain.
We have several ways to go:
a) continue with the current extra dependencies situation like in zope.component, and in fact clean up other packages that define ZCML to declare ZCML extra dependencies.
I did this in zope.component out of desperation. (I was preparing to teach a PyCon tutorial on using zope.component outside of Zope.) I'm not at all happy with it, however, I'd be in favor of continuing it for existing packages with zcml implementations so as not to introduce backward incompatibilities. I'd rather not do it for new packages. IMO, introducing an extra is like introducing a new package and in a rather complicated way.
b) pull out all ZCML implementations from where they are now and put them in special ZCML implementation packages. We could for instance have zcml.component, or zope.component_zcml, or zope.configuration.component. We had a bit of a side-tracked discussion about naming and namespace packages here.
I think this is the right way to go for new software.
c) pull out only those ZCML implementations that cause extra dependencies beyond zope.configuration. So, we extract the bits of zope.component into a new package, but we don't extract bits from zope.security.
Too complicated imo. :)
I personally don't like extras. I think the ideal situation would be if packages had *no* extras at all (even test extras), as it complicates reasoning about the dependency structure.
+1 ...
For that reason, a) is not really an option for me.
As I said above, I'm for a) because I think it is less disruptive, even though I share your distaste for extras. Jim -- Jim Fulton Zope Corporation
Jim Fulton wrote at 2009-2-8 13:00 -0500:
... IMO, introducing an extra is like introducing a new package and in a rather complicated way.
I agree with the first part of your sentence -- but cannot follow you with the second part: How can "'extra' : <sequence of required distributions>" be more complicated than creating, maintaining and distributing a complete package? -- Dieter
On Feb 10, 2009, at 1:49 PM, Dieter Maurer wrote:
Jim Fulton wrote at 2009-2-8 13:00 -0500:
... IMO, introducing an extra is like introducing a new package and in a rather complicated way.
I agree with the first part of your sentence -- but cannot follow you with the second part:
How can "'extra' : <sequence of required distributions>" be more complicated than creating, maintaining and distributing a complete package?
Because you have to remember to test each valid permutation of the package. I bet no one does. Also, users have to be aware of the extras. PyPI doesn't advertise extras nor are there standard ways to document them. In general, it makes an already complicated packaging system more complicated. Jim -- Jim Fulton Zope Corporation
Hey, So the general idea would be to remove the complication extras introduce in reasoning about packages. Extras can be removed in two ways: * carefully restructure dependency relationships between packages so that extras are no longer needed (typically for test extras this can be done) * extract the code that is causing the extra and move it, either into an existing package or into a new one. zope.component is a prime candidate for this treatement. At most, zope.component should provide implementations of configuration actions that do not involve extra dependencies like zope.security. The actual implementation of the directives can then reuse these core actions and add the extra registrations they need. I think there's good evidence that zope.component shouldn't be providing the implementations directly: * repoze.zcml - reimplements the directives sans security and with concern for multiple registries * grokcore.component - reimplements the functionality of these actions but not reusing the action code, simply using provideAdapter and provideUtility as underlying actions. So, zope.component is both doing too much and not pulling its weight in helping with configuration, as we have two packages that entirely go around its configuration implementations right now. I think we should study repoze.zcml and see whether we cannot fold part of that implementation into zope.component as actions that can be reused by both repoze.zcml as well as grokcore.component. We can then move the implementations of the standard security-conscious actions from zope.component, perhaps into zope.security (as that's really what the extra dependency is all about, and the extra bit that gets added to the standard directives is security-support), or perhaps into a newly created package. I suspect that if we create a new ZCML only packages we'd get very far with something that would replace the ZCML defined in zope.component and zope.security both, and with another package that tackles various browser oriented directives. We're not looking at vastly expanding the amount of packages. Regards, Martijn
Jim Fulton wrote at 2009-2-10 14:01 -0500:
On Feb 10, 2009, at 1:49 PM, Dieter Maurer wrote:
Jim Fulton wrote at 2009-2-8 13:00 -0500:
... IMO, introducing an extra is like introducing a new package and in a rather complicated way.
I agree with the first part of your sentence -- but cannot follow you with the second part:
How can "'extra' : <sequence of required distributions>" be more complicated than creating, maintaining and distributing a complete package?
Because you have to remember to test each valid permutation of the package. I bet no one does.
But that is the same when each extra is represented by an individual package. Then, too, you have to test each valid combination -- and few will do it.
Also, users have to be aware of the extras. PyPI doesn't advertise extras
I am interested in extras only when I am interested in the package itself. Of course, the package should document in some way relevant extras.
nor are there standard ways to document them.
I recently looked at documentation for a few "standard" packages on PyPI -- and apart from all using "rest" and a bit of classifiction, I could not detect much "standard" for them, too.
In general, it makes an already complicated packaging system more complicated.
That's something I do not get... An extra is a shorthand for a separate package with a few extra dependancies. Sure, shorthands are not strictly necessary. Sure, complexity increases slightly. Nevertheless, they are often valuable. -- Dieter
participants (10)
-
Adam GROSZER -
Dan Korostelev -
Dieter Maurer -
Hanno Schlichting -
Jim Fulton -
Martijn Faassen -
Martin Aspeli -
Shane Hathaway -
Tres Seaver -
Wichert Akkerman