Re: [Zope] Acquisition / proxying object
On Monday 25 February 2008 23:52:26 Joerg Baach wrote:
Hi *,
But somehow I have the feeling it has more to do with the 'and the
container is not wrapped' part of the message. Not that I can make sense
of it ;-)
Mmm, after even more searching, and not understanding I found
http://www.mail-archive.com/[EMAIL PROTECTED]/msg11438.html
and changed my code to:
def __of__(self, parent):
'''foo'''
if not hasattr(parent,'aq_base'):
return self
folder,id = self.remoteid.split(':')
acl = parent.unrestrictedTraverse(folder)
You're now doing no security checks on traversal, probably thats why you don't
get any Unauthorized exceptions :-)
- peter.
remote = acl.getUser(id)
return Acquisition.ImplicitAcquisitionWrapper(aq_base(self),
aq_base(remote).__of__(parent))
Now, this actually seems to work. If only I knew why
Cheers,
Joerg
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Acquisition / proxying object
Hi Peter, acl = parent.unrestrictedTraverse(folder) when changing to acl = parent.restrictedTraverse(folder) I still don't get the Unauthorized exceptions. Anyhow, I will have to do a bit more wrapping, and then see if the solutions survive the security testing ;-) Cheers, Joerg signature.asc Description: OpenPGP digital signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] 2.10 and ZClasses
We are still running 2.7.5 but really want to upgrade. Changes.txt in 2.10.5 state ZClasses are deprecated. CAN they still be used?? Not at all or just not recommended and why? What is the highest version we can safely upgrade to then? Thanks Allen ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Acquisition / proxying object
This is maybe a naive suggestion but if Zope's TTW execution (e.g.
Python Scripts) can't find a __roles__ on the object at hand doesn't
that just mean that the class wasn't initialized with any security.
class LDAPProxy(Folder):
...
from Globals import InitializeClass
InitializeClass(LDAPProxy)
That should set the *__roles__ on all it's methods.
Joerg Baach wrote:
Hi *,
I am trying to have a folderish object that acquires from a user object
(ldapuserfolder). It should have its own properties and contents, but
fall back to the ones of the ldap user.
I have created an object, extending Folder, and it behaves nicely in
zopectl debug. When I try to access it through e.g. a python script I
get an:
Error Type: Unauthorized
Error Value: Unable to find __roles__ in the container and the container
is not wrapped. Access to 'dn' of test, acquired through (LDAPProxy at
/testfolder/ldapproxy), denied.
I am sure its my lack of understanding of acquisition. I am trying to
bascially put ldap user object 'on top' of the aquisition line (with the
ldapproxy at the bottom), but obviously failing in doing so. Any ideas?
Cheers,
Joerg
8 excerpt from code ---
class LDAPProxy(Folder):
meta_type='LDAPProxy'
def __init__(self, id, remoteid,title='',REQUEST=None):
self.id = id
self.title = title
self.remoteid = remoteid
def __of__(self, parent):
if not hasattr(parent,'aq_base'):
return self
folder,id = self.remoteid.split(':')
acl = parent.restrictedTraverse(folder)
remote = acl.getUser(id)
return Folder.__of__(self,parent.__of__(remote))
--- teststructure--
/testfolder/
ldapproxy (LDAPProxy)
acl_users/
testscript (.py)
8 testscript -
return context.ldapproxy.dn
traceback--
Traceback (most recent call last):
File /home/joerg/zope/Zope-2.8.5/lib/python/ZPublisher/Publish.py,
line 113, in publish
request, bind=1)
File /home/joerg/zope/Zope-2.8.5/lib/python/ZPublisher/mapply.py,
line 88, in mapply
if debug is not None: return debug(object,args,context)
File /home/joerg/zope/Zope-2.8.5/lib/python/ZPublisher/Publish.py,
line 40, in call_object
result=apply(object,args) # Type scr to step into published object.
File
/home/joerg/zope/Zope-2.8.5/lib/python/Shared/DC/Scripts/Bindings.py,
line 311, in __call__
return self._bindAndExec(args, kw, None)
File
/home/joerg/zope/Zope-2.8.5/lib/python/Shared/DC/Scripts/Bindings.py,
line 348, in _bindAndExec
return self._exec(bound_data, args, kw)
File
/home/joerg/zope/Zope-2.8.5/lib/python/Products/PythonScripts/PythonScript.py,
line 323, in _exec
result = f(*args, **kw)
File Script (Python), line 1, in testscript
File
/home/joerg/zope/Zope-2.8.5/lib/python/AccessControl/ImplPython.py,
line 727, in guarded_getattr
aq_acquire(inst, name, aq_validate, validate)
File
/home/joerg/zope/Zope-2.8.5/lib/python/AccessControl/ImplPython.py,
line 669, in aq_validate
return validate(inst, object, name, v)
File
/home/joerg/zope/Zope-2.8.5/lib/python/AccessControl/ImplPython.py,
line 563, in validate
self._context)
File
/home/joerg/zope/Zope-2.8.5/lib/python/AccessControl/ImplPython.py,
line 293, in validate
accessed, container, name, value, context)
File
/home/joerg/zope/Zope-2.8.5/lib/python/AccessControl/ImplPython.py,
line 808, in raiseVerbose
raise Unauthorized(text)
Unauthorized: Unable to find __roles__ in the container and the
container is not wrapped. Access to 'dn' of test, acquired through
(LDAPProxy at /testfolder/ldapproxy), denied.
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
--
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Need Server
Hi: I am out of business and I need someone to host a client's site (for which they will obviously pay). Requires Zope 2.78 and ZMySQL. Have everything you need. I would need to get into the ZMI to set things up, but don't need server access. Please write me off-list. TIA, Victor ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] 2.10 and ZClasses
--On 26. Februar 2008 07:30:04 -0500 Allen Schmidt Sr. [EMAIL PROTECTED] wrote: We are still running 2.7.5 but really want to upgrade. Changes.txt in 2.10.5 state ZClasses are deprecated. Deprecated means: they are still working (or at least they should). -aj pgpuaxUvcwh84.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] 2.10 and ZClasses
--On 26. Februar 2008 09:46:31 -0500 Allen Schmidt Sr. [EMAIL PROTECTED] wrote: Is there anyone out there still using ZClasses on later versions of Zope?? Care to share any experiences? Off-list responses are fine. Please stay on the list. Such experiences are of public interested and should be available in the archive for our childs. Andreas pgppfGSxxsNP6.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] 2.10 and ZClasses
Is there anyone out there still using ZClasses on later versions of Zope?? Care to share any experiences? Off-list responses are fine. Thanks! Allen Andreas Jung wrote: --On 26. Februar 2008 07:30:04 -0500 Allen Schmidt Sr. [EMAIL PROTECTED] wrote: We are still running 2.7.5 but really want to upgrade. Changes.txt in 2.10.5 state ZClasses are deprecated. Deprecated means: they are still working (or at least they should). - aj ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: 2.10 and ZClasses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: --On 26. Februar 2008 09:46:31 -0500 Allen Schmidt Sr. [EMAIL PROTECTED] wrote: Is there anyone out there still using ZClasses on later versions of Zope?? Care to share any experiences? Off-list responses are fine. Please stay on the list. Such experiences are of public interested and should be available in the archive for our childs. His post *was* on the list: I saw it on gmane.org. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHxEfx+gerLs4ltQ4RAs9zAJ0c23A29SJQSPauB6VYuBx8BmKB/wCdG94q O937j6+ZTGpa3anJ08bC5QU= =gppX -END PGP SIGNATURE- ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: 2.10 and ZClasses
--On 26. Februar 2008 12:10:09 -0500 Tres Seaver [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: --On 26. Februar 2008 09:46:31 -0500 Allen Schmidt Sr. [EMAIL PROTECTED] wrote: Is there anyone out there still using ZClasses on later versions of Zope?? Care to share any experiences? Off-list responses are fine. Please stay on the list. Such experiences are of public interested and should be available in the archive for our childs. His post *was* on the list: I saw it on gmane.org. The followup was about off-list responses are fine. Andreas pgpiiBfW44Yfd.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: 2.10 and ZClasses
I understand and appreciate your responses. Finally got some things straightened out and after changing DA settings to point to real database servers (instead of localhost), and commenting things out that were calling unneeded parts, I am able to get our site up (on some pages) with yesterdays news stored in the Data.fs. I am able to view an actual news ZClass objects with our site header and footer wrapped around it. Not bad. That shows they do work. Long way to go but it's a start But, on the page that does the catalog lookup of the day's news stories, it is a blank page. No errors in the error_log. But if I go to the ArchiveCatalog (our name for our Catalog) and click on the Catalog tab in the ZMI, I get this error: Traceback (innermost last): Module ZPublisher.Publish, line 119, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 42, in call_object Module Shared.DC.Scripts.Bindings, line 313, in __call__ Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec Module App.special_dtml, line 178, in _exec Module DocumentTemplate.DT_Let, line 76, in render Module DocumentTemplate.DT_In, line 584, in renderwb Module Products.ZCatalog.Lazy, line 144, in __getitem__ IndexError: list index out of range All the other tabs work. Allen Andreas Jung wrote: --On 26. Februar 2008 12:31:49 -0500 Allen Schmidt Sr. [EMAIL PROTECTED] wrote: I think he just meant that others should keep their responses to me on the list...as I offered the option to respond off-list, with the intention of keeping the noise down to the couple guys who may benefit and still use ZClasses. Although I don#t care much about ZClasses I would like to hear if there are any issues with them. Public noise is not a problem. If known issues are discussed in public than other people might find them later in the archive. That's just the whole point why I would like to avoid private discussions about things of public interest. Andre as ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope 3 and Rails - a pragmatic and agile comparation (put the hype aside)
Here is a follow up I wrote that fell off the list. The original poster probably thought he was posting to the zope@zope.org but I leave his id off just in case he didn't. I am reposting it here mainly because he makes several good points. -Tim I find zope's through the web editing it's worst aspect. It would make a great optional add-on, but to make the root of the site only editable through the web is just a disaster. I could vote for an optional add-on. BTW I meant to say google gadgets. The point is that there is always far more innovation outside your company than inside and companies are looking for software that helps them tap into that talent. 2. object database. Perfect for web services with changing schemas. It's great, but I wish it wasn't mapped directly to URLs. There should be an abstraction, like the controller in MVC systems. I could also vote for this but apache does a lot of this for you. DTML is horrible because it looks like XML but isn't. It should either be XML, like TAL, which I think is great, or be nothing like it, like django's templating language. If you are talking about reading dtml I share your pain, but if you are talking about writing it then you have a built in filter. When your page starts to look ugly rethink your problem. For example, these days you can program tabs with secondary menus using just two dtml-in loops if you start with tabs that only require css http://labs.silverorange.com/images/tabsupdate/about.html 5. a ZMI which allows zope to be an easy to administer database. Easy enough for distribution to powerusers. Useful, but should be turn-off-able. I can vote for this as well I want to be able to have a zope site entirely in the file system with no ZODB, so I can keep it in subversion, and use normal things like grep, patch and sed to apply changes to the whole codebase. You can do this with zope 2 but you can also allow user customization that you can later migrate in to the filesystem code. If I want it in the site to do a CMS type application, I want to put it inside my File System Site code, not put a file system site object into it. Not sure what you mean here. You aren't forced to put filesystem objects into the ZODB. The folders/tree structure of zope is a natural navigational device that is very useful. Check out the book Don't make me think. Zope 3 has great ideas (components, interfaces, views, maybe PAU) but zope 2 (dtml, TTW, Plone) is what pulls them in the door. And you have to get them in the door before they will buy. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Static adquirable resource
Hi! Some weeks ago Tres point us how to declare static resources with five You could create a configure.zcml file for your product and put some code like these: configure xmlns:browser=http://namespaces.zope.org/browser; browser:page for=* name=ZSmanage template=recursos/ZSmanage.pt permission=zope2.Public / /configure and magically you could use it as: http://server:port/ZSmanage But if you try to use ZSmanage as an acquired object you could Can I do something at this respect? I would like to use ZSmanage in a different context, can I? Thanks! -- Mis Cosas http://blogs.sistes.net/Garito Zope Smart Manager http://blogs.sistes.net/Garito/670 ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Zope Tests:
Summary of messages to the zope-tests list. Period Mon Feb 25 12:00:00 2008 UTC to Tue Feb 26 12:00:00 2008 UTC. There were no messages. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: buildout 'versions' and 'develop' conflict
Christian Theune wrote: Martijn Faassen schrieb: [snip] I think the explicit versus implicit discussion has no place here. Placing a package on the 'develop' line is a very explicit action, and you place it on that line because you want to *develop on it*. Having another package being picked up is surprising. OTOH it makes you aware about potential version mismatches very early, because you try to develop on a package that doesn't seem to be supported by that particular buildout. So maybe you, for example actually wanted/should increase the version number. I don't understand what you're getting at. A development package will *never* be supported by a package listing in a particular buildout, as it should always have a 'dev' marker in its version number in setup.py. If it's listed in any list of fixed versions, it's always going to be wrong. And yes, when you release a package you've been developing you do need to update the versions listing of the buildout that depends on it. It's clear enough from what's listed in 'develop' what you need to be updating. Did really nobody run into this surprise before? I am really surprised at that. I mean, you were working with a buildout with a fixed version list, added a package to 'develop' and then (after some head-scratching) noticed your changes weren't being picked up at all, and then you *weren't* surprised about it and wondering what to do about it? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: buildout 'versions' and 'develop' conflict
Hi, Martijn Faassen schrieb: Christian Theune wrote: Martijn Faassen schrieb: [snip] I think the explicit versus implicit discussion has no place here. Placing a package on the 'develop' line is a very explicit action, and you place it on that line because you want to *develop on it*. Having another package being picked up is surprising. OTOH it makes you aware about potential version mismatches very early, because you try to develop on a package that doesn't seem to be supported by that particular buildout. So maybe you, for example actually wanted/should increase the version number. I don't understand what you're getting at. A development package will *never* be supported by a package listing in a particular buildout, as it should always have a 'dev' marker in its version number in setup.py. If it's listed in any list of fixed versions, it's always going to be wrong. And yes, when you release a package you've been developing you do need to update the versions listing of the buildout that depends on it. It's clear enough from what's listed in 'develop' what you need to be updating. Did really nobody run into this surprise before? I am really surprised at that. I mean, you were working with a buildout with a fixed version list, added a package to 'develop' and then (after some head-scratching) noticed your changes weren't being picked up at all, and then you *weren't* surprised about it and wondering what to do about it? Nope. I'm not always working against a fixed version list. E.g. when I developt z3c.zalchemy then this is a library package, not an application, so I don't fix the versions but let anything that satisfies the the requirements in setup.py come in. In this situation I might use a checkout of SQLAlchemy that doesn't match the version requirement so it doesn't get picked. (I.e. there are two branches of zalchemy, one for SA 0.3 and one for 0.4) I don't want to start developing on the 0.3 branch using SA 0.4 accidentally. buildout can be and is used in a much broader way than just applications that provide fixed versions. Christian -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: buildout 'versions' and 'develop' conflict
David Pratt wrote: Hi Martijn. I respect the points you make, but disagree with your comments. Wichert's reply accurately articulates what we are asking buildout to do. I share this view. It's not very useful to talk about a we asking buildout to do things when there is clearly a debate and no we. On a personal note, I tend to rely on my own version lists but refer to the online lists (for support in creating them). On explicit vs implicit, it is debatable any time you consider incorporating implicit behaviour. We're not considering incorporating implicit behavior. We're debating two competing explicit behaviors. When you make the point about versions duplication, you may not be considering the utility of buildout. In fact, a buildout does not require a setup.py at all. setup.py is only a requirement for packaging in python. Buildout is already being used together with other packaging solutions and in other ways as I have previously mentioned. I don't understand your point. Explain to me how you can use the 'develop' line *without* it pointing to a package with a setup.py? Explain to me how 'versions' can be applied to version numbers of things that are *not* eggs? There is a genuine debate possible over what 'develop' actually does. If you ignore version pinning, you can have two descriptions: * if you want to develop a package, put it under 'develop'. * listing a package under 'develop' adds it to the package search path for packages *and* this package will trump any other versions available elsewhere on the path. These descriptions are equivalent, though one is task-oriented and the other one talks about the details of what's going on. I had internalized the former model, and was surprised when it was broken when version pinning was included. Evidently the rule for 'develop' is now: * listing a package under 'develop' adds it to the package search path for packages *and* this package will trump any other versions available elsewhere on the path *unless* there is an explicit version pinning indicator that says you want to use that version of the package. The task oriented description to develop a package becomes: * if you want to develop a package, put it under 'develop', and just to be sure it isn't pinned in some version list somewhere, add a 'versions' entry to your buildout if it doesn't exist already, and then list package_name = in it to make sure it is being picked up. (alternatively you can make the user check the versions lists for the presence of the package and only if it there have the user list it. Or yet another alternative is to run the buildout in verbose mode and look at what versions pass by) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: buildout 'versions' and 'develop' conflict
Christian Theune wrote: Martijn Faassen schrieb: [snip] It's a clear DRY violation, the name of the package (and even the version number) repeats here. It's not clear to me that it's a DRY violation (see my argument that those functions are actually orthogonal). The rule for the most common use case is now: If you want to develop a package, add it to 'develop' *and* create a versions section if it doesn't exist, let the 'versions' line in [buildout] point to it, and add the package_name = to it. I see a repetition in the package name here. You list it in two places. I think that's a DRY violation given that wanting a package listed in develop to be picked up is the most common use case. When applying DRY we still need to beware that we don't lock out combinations that are currently possible/helpful. Why would I want to list a package under 'develop' in a buildout and not have it be picked up? A combination only needs to be possible if it is helpful, so could you please give me an example a use case where this doesn't happen that is helpful? I'm really struggling to come up with a use case where you want to add a development package to the search path and then have it never being picked up. I experimented with recipes that change other recipes' configuration at run-time, but had a bad experience because of the part-ordering that prevents this, otherwise I'd say you could use a recipe for simpler declaration of develop eggs. That would make you type more in each buildout, though. I just want to add the behavior to buildout. Then I can tell people, if you want to develop a package, use really_develop. I started trying to add a test to buildout that demonstrates the current behavior (not really_develop). Strangely enough, it fails! I asked on the distutils list what I'm doing wrong. The branch is 'faassen-develop'. (there are some unrelated test failures too, but they exist on the trunk too for some reason) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: buildout 'versions' and 'develop' conflict
Previously Martijn Faassen wrote: Christian Theune wrote: Martijn Faassen schrieb: [snip] It's a clear DRY violation, the name of the package (and even the version number) repeats here. It's not clear to me that it's a DRY violation (see my argument that those functions are actually orthogonal). The rule for the most common use case is now: If you want to develop a package, add it to 'develop' *and* create a versions section if it doesn't exist, let the 'versions' line in [buildout] point to it, and add the package_name = to it. I see a repetition in the package name here. You list it in two places. I think that's a DRY violation given that wanting a package listed in develop to be picked up is the most common use case. That highly depends on how you work. I normally do not pin to exact revisions but to ranges, which work just fun with dev eggs. If you don't want to pin something - remove the pin. Don't expect something to magically make your pin go away. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: buildout 'versions' and 'develop' conflict
[Originally sent to Martin only; meant to send to the list.] On Mon, Feb 25, 2008 at 5:18 PM, Martijn Faassen [EMAIL PROTECTED] wrote: Meanwhile, you're satisfied already with actually looking at setup.py of the develop package and then repeating the version number *too*. It's fascinating how people look differently at these things, isn't it? Heh. We have buildouts where multiple versions of a package are used by different parts of what's built. There's a real value in separating the meanings of develop and version requirements. We also typically work with the following settings, just to make sure we don't leave any information out of our build configuration: [buildout] allow-picked-versions = false use-dependency-links = false Having to repeat on ocaission isn't wonderful, but it's actually pretty unusual, and far better than leaving something out that can't be recovered later. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: buildout 'versions' and 'develop' conflict
Wichert Akkerman wrote: Previously Martijn Faassen wrote: Christian Theune wrote: Martijn Faassen schrieb: [snip] It's a clear DRY violation, the name of the package (and even the version number) repeats here. It's not clear to me that it's a DRY violation (see my argument that those functions are actually orthogonal). The rule for the most common use case is now: If you want to develop a package, add it to 'develop' *and* create a versions section if it doesn't exist, let the 'versions' line in [buildout] point to it, and add the package_name = to it. I see a repetition in the package name here. You list it in two places. I think that's a DRY violation given that wanting a package listed in develop to be picked up is the most common use case. That highly depends on how you work. I normally do not pin to exact revisions but to ranges, which work just fun with dev eggs. I'm confused. How do you work with ranges in a versions section? I'm talking about this construction: [buildout] develop = my_package versions = some_release [some_release] my_package = 3 I didn't realize you could work with ranges there? If you don't want to pin something - remove the pin. Don't expect something to magically make your pin go away. I do want to pin everything but the packages I'm presently developing. Do you want your 'develop' packages to be picked up if there's a released version of the package available somewhere, and your ranges allow both to be picked up equally, by the way? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: buildout 'versions' and 'develop' conflict
Previously Martijn Faassen wrote: Wichert Akkerman wrote: Previously Martijn Faassen wrote: Christian Theune wrote: Martijn Faassen schrieb: [snip] It's a clear DRY violation, the name of the package (and even the version number) repeats here. It's not clear to me that it's a DRY violation (see my argument that those functions are actually orthogonal). The rule for the most common use case is now: If you want to develop a package, add it to 'develop' *and* create a versions section if it doesn't exist, let the 'versions' line in [buildout] point to it, and add the package_name = to it. I see a repetition in the package name here. You list it in two places. I think that's a DRY violation given that wanting a package listed in develop to be picked up is the most common use case. That highly depends on how you work. I normally do not pin to exact revisions but to ranges, which work just fun with dev eggs. I'm confused. How do you work with ranges in a versions section? I'm talking about this construction: [buildout] develop = my_package versions = some_release [some_release] my_package = 3 I didn't realize you could work with ranges there? I don't, but I can put ranges in setup.py. If you don't want to pin something - remove the pin. Don't expect something to magically make your pin go away. I do want to pin everything but the packages I'm presently developing. Do you want your 'develop' packages to be picked up if there's a released version of the package available somewhere, and your ranges allow both to be picked up equally, by the way? Only if it has a newer version number or I somehow enforce that. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: buildout 'versions' and 'develop' conflict
Martijn Faassen a écrit :
(...)
I think the term 'develop' is badly chosen. You are right if you argue while
having the meaning of 'develop' in mind. You are explaining what you think a
'develop' option should be. A 'develop' option means: I want to 'develop' on
this package, so I want it active, otherwise I don't put 'develop'.
But probably the feature has been created before the name 'develop' was chosen,
and it should have an other name ('egg_path'? 'local_egg'?).
However something has to be done because some people find it not logical, some
other people will probably have headaches with it.
The two easiest choices are 1) issue a clear warning in stderr, or 2) rename
'develop' to something else.
Christophe
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: buildout 'versions' and 'develop' conflict
On Feb 26, 2008, at 9:38 AM, Christophe Combelles wrote: Martijn Faassen a écrit : (...) The two easiest choices are 1) issue a clear warning in stderr, or 2) rename 'develop' to something else. So, the people that understand either get spammed with warning messages every build, or have to change all their builds in order to accommodate your thinking? We all know what the solution is, it was supplied at the beginning of the thread: [versions] mynewpin = somenewversion_dev Aaron Lehmann___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: buildout 'versions' and 'develop' conflict
Christian Theune wrote: [snip] Nope. I'm not always working against a fixed version list. E.g. when I developt z3c.zalchemy then this is a library package, not an application, so I don't fix the versions but let anything that satisfies the the requirements in setup.py come in. This thread is called 'buildout versions and develop conflict, and I was talking about that topic. I can see how this is related to other topics from the perspective of consistency arguments, but perhaps you should be more clear. :) In this situation I might use a checkout of SQLAlchemy that doesn't match the version requirement so it doesn't get picked. (I.e. there are two branches of zalchemy, one for SA 0.3 and one for 0.4) And you're listing both of them in 'develop'? Fred pointed out to me that you might want to rely on the same package but different versions multiple times in a buildout. I can see how this can be useful, but I don't see how one can use the 'versions' construction of the [buildout] section and do this. I don't want to start developing on the 0.3 branch using SA 0.4 accidentally. I think that this information should be codified in the setup.py requirements of your package. If it relies on 0.3, it should say so with a dependency range. I don't think pinned versions are very useful to stop you from making accidents here. buildout can be and is used in a much broader way than just applications that provide fixed versions. My summary: The consistency argument indicates to me that version pinning should have the same effect as listing version constraints in setup.py. A reasonable argument. Since version constraints are the most specific constraints possible, if there is no constraint conflict they will be the ones picked. There is a use case argument that allows the listing of multiple versions of a development package in 'develop' at the same time, and then have different parts of the buildout pick up on it. Sounds like a valid use case. I wonder though what will be picked up if you *don't* specify the version explicitly later on in your buildout. Unspecified behavior? Having multiple versions of the same package listed in the 'develop' section can never work, I take it, in the face of version pinning. If you have two versions listed in 'develop' and want to use different ones in different sections of your buildout, you can't do this in the face of a global version list, right? I'd say the consistency argument implies buildout should fail with an error if you try to use two different versions of a package while the version is pinned down globally. The task-driven and most-common use case argument (I want to develop!) have made the 'develop' section trump any other listed packages if the version constraints allow both. This is the current behavior. The task I am concerned about entails wanting to hack on a package that is pinned down. This is in my experience very common in the face of shared lists of pinned versions (from the KGS or Grok). In the face of such lists, it's not very pleasant to have to explain to people who want to hack on a package that they should also add the package to the 'versions' section of a buildout to override any entry of them in the list. The goal of this feature is to allow us to tell people the following: * if you want to hack on a package, check it out into your buildout and add it to 'really_develop', and then re-run bin/buildout. and that this will work even in the face of explicit version pinning. My proposal is to add a new feature to buildout, temporarily called 'really_develop', which places a package on the develop list and trumps version pinning. We can debate whether it should also be trumping any version constraints of other packages as well - I don't know whether this is a good idea or not. I think perhaps it should. It *should* still obey the constraints listed in the setup.py of the package under development however. In constraint terms, there would be the ability to override existing constraints by placing a package in 'really_develop'. You could see this as an 'override' version: a package listed in 'really_develop' gets a version 'override' that is guaranteed to fulfill any constraints on version *and* is the most-preferred version. Listing a package in 'develop' doesn't change the version but makes that version the most preferred version if multiple versions of that package would fulfill the set of constraints. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: buildout 'versions' and 'develop' conflict
Aaron Lehmann a écrit : On Feb 26, 2008, at 9:38 AM, Christophe Combelles wrote: Martijn Faassen a écrit : (...) The two easiest choices are 1) issue a clear warning in stderr, or 2) rename 'develop' to something else. So, the people that understand either get spammed with warning messages every build, You would get a warning *only* if you have specified a 'develop' option and that option has no effect (because of a version). I suppose nobody work in such a situation because it makes no sense. Either you want to specify a version to let your develop-egg be used, or you just remove the develop option. Nobody wants to specify an option while knowing it won't be used. The warning is just to tell you have specified 'develop=' but your develop-egg is not used and the egg version x.x is used instead. Christophe or have to change all their builds in order to accommodate your thinking? We all know what the solution is, it was supplied at the beginning of the thread: [versions] mynewpin = somenewversion_dev Aaron Lehmann ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: buildout 'versions' and 'develop' conflict
Aaron Lehmann wrote: On Feb 26, 2008, at 9:38 AM, Christophe Combelles wrote: Martijn Faassen a écrit : (...) The two easiest choices are 1) issue a clear warning in stderr, or 2) rename 'develop' to something else. So, the people that understand either get spammed with warning messages every build, or have to change all their builds in order to accommodate your thinking? We all know what the solution is, it was supplied at the beginning of the thread: [versions] mynewpin = somenewversion_dev It's longer and shorter: * longer: create a 'versions' section if it isn't there yet, and point to it from [buildout] with 'versions'. (the versions section may not be there yet if this buildout.cfg extends another one with such a section) * shorter: [versions] mynewpin = Removes the pin. In the absence of a pin, it will pick the newest version. Or perhaps I'm wrong about this somehow, as I couldn't get the test case to work when I added it to buildout. :) There are two problems with this solution, both usability related: * People tend to be surprised when they first run into this. The solution is non-obvious in the face of external version lists. It can be expected people will be surprised in the future. * You make people type more, repeating a version name, in a common case (in the face of KGS) So, we're looking at a way to increase the usability of a common task: hack on a package without having to understand its place in a potentially very complicated dependency structure. The simplest solution I see to these problems is to add another option to buildout that does both at the same time (and perhaps override all other constraints), and direct people to that should they wish to develop a package. The name 'develop' was picked which is understandable historically, and it can't be changed. It's consistent with the behavior of easy_install. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: buildout 'versions' and 'develop' conflict
Hey, Thanks everybody for this discussion. I'm going to bail out now, and I want to share some of my conclusions: * We're going to have to live with the current 'versions/develop' story for a while. I've started try to document the existing behavior in buildout's doctests (faassen-develop) branch. I'll also document it for Grok. * It would be nice if there was some way to override dependency constraints: point at a (development) package and give it a special version number that *always* satisfies all dependency constraints and is *always* the most specific package to do so. * All this makes me think again about the topic of dependency constraint resolution with special override nodes (also in relation to the addition of 'or' constraints to setuptools). * Doing a good dependency constraint resolution needs extensions to the cheeseshop: as I understand it, no dependency information is online right now and the package needs to be downloaded in order to inspect it. Basically it'd be nice if the egg_info directory was published for each release. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: buildout 'versions' and 'develop' conflict
On Feb 26, 2008, at 10:29 AM, Martijn Faassen wrote: Aaron Lehmann wrote: On Feb 26, 2008, at 9:38 AM, Christophe Combelles wrote: Martijn Faassen a écrit : (...) The two easiest choices are 1) issue a clear warning in stderr, or 2) rename 'develop' to something else. So, the people that understand either get spammed with warning messages every build, or have to change all their builds in order to accommodate your thinking? We all know what the solution is, it was supplied at the beginning of the thread: [versions] mynewpin = somenewversion_dev It's longer and shorter: * longer: create a 'versions' section if it isn't there yet, and point to it from [buildout] with 'versions'. (the versions section may not be there yet if this buildout.cfg extends another one with such a section) If you're extending a buildout with a versions section, you already have one. That's what extending the buildout did for you. * shorter: [versions] mynewpin = This will burn you if your develop egg is not the highest available version (for example, you are working on a bugfix for an en egg that is not bleeding edge). Also, some folks require everything be pinned. So, we're looking at a way to increase the usability of a common task: hack on a package without having to understand its place in a potentially very complicated dependency structure. If you are hacking on an egg, you should know what the current version is, and how your version is different. If you don't, your confusion is deserved. Aaron Lehmann___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: buildout 'versions' and 'develop' conflict
Hi, Martijn Faassen schrieb: Christian Theune wrote: [snip] Nope. I'm not always working against a fixed version list. E.g. when I developt z3c.zalchemy then this is a library package, not an application, so I don't fix the versions but let anything that satisfies the the requirements in setup.py come in. This thread is called 'buildout versions and develop conflict, and I was talking about that topic. I can see how this is related to other topics from the perspective of consistency arguments, but perhaps you should be more clear. :) Sorry, I thought I was. In this situation I might use a checkout of SQLAlchemy that doesn't match the version requirement so it doesn't get picked. (I.e. there are two branches of zalchemy, one for SA 0.3 and one for 0.4) And you're listing both of them in 'develop'? No, I usually only eneter one. Fred pointed out to me that you might want to rely on the same package but different versions multiple times in a buildout. I can see how this can be useful, but I don't see how one can use the 'versions' construction of the [buildout] section and do this. That's a valid use case too, it's not mine though (right now). I don't want to start developing on the 0.3 branch using SA 0.4 accidentally. I think that this information should be codified in the setup.py requirements of your package. If it relies on 0.3, it should say so with a dependency range. I don't think pinned versions are very useful to stop you from making accidents here. That's what I do. That allows me to notice when I include the wrong develop package because it will not be picked up. (In spite of other people that posted to this thread who seem to prefer not to care about this problem during development.) buildout can be and is used in a much broader way than just applications that provide fixed versions. My summary: The consistency argument indicates to me that version pinning should have the same effect as listing version constraints in setup.py. A reasonable argument. Since version constraints are the most specific constraints possible, if there is no constraint conflict they will be the ones picked. Right, that's my understanding as well. There is a use case argument that allows the listing of multiple versions of a development package in 'develop' at the same time, and then have different parts of the buildout pick up on it. Sounds like a valid use case. I wonder though what will be picked up if you *don't* specify the version explicitly later on in your buildout. Unspecified behavior? Good question. Having multiple versions of the same package listed in the 'develop' section can never work, I take it, in the face of version pinning. If you have two versions listed in 'develop' and want to use different ones in different sections of your buildout, you can't do this in the face of a global version list, right? I'd say the consistency argument implies buildout should fail with an error if you try to use two different versions of a package while the version is pinned down globally. I think you're right. I haven't given thought whether making buildout fail is a good idea, it might be though. The task-driven and most-common use case argument (I want to develop!) have made the 'develop' section trump any other listed packages if the version constraints allow both. This is the current behavior. The task I am concerned about entails wanting to hack on a package that is pinned down. This is in my experience very common in the face of shared lists of pinned versions (from the KGS or Grok). In the face of such lists, it's not very pleasant to have to explain to people who want to hack on a package that they should also add the package to the 'versions' section of a buildout to override any entry of them in the list. The goal of this feature is to allow us to tell people the following: * if you want to hack on a package, check it out into your buildout and add it to 'really_develop', and then re-run bin/buildout. and that this will work even in the face of explicit version pinning. I really hate the term `really_develop` and I don't like having two develop statements. Here's an idea: Let `develop` trump version pinning, but not any other constraints. As far as I can see this would allow both of our scenarios to work or continue to work. [snip] Christian -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
