| *** hazmat has joined #zope3-dev | 00:03 | |
| *** ChanServ sets mode: +o hazmat | 00:03 | |
| *** RaFromBRC_ has joined #zope3-dev | 00:19 | |
| *** RaFromBRC has quit IRC | 00:20 | |
| *** RaFromBRC_ is now known as RaFromBRC | 00:21 | |
| *** batlogg has quit IRC | 00:28 | |
| *** RaFromBRC is now known as RaFromBRC|lunch | 00:29 | |
| *** dokai has quit IRC | 00:49 | |
| *** hazmat has quit IRC | 00:53 | |
| *** dokai has joined #zope3-dev | 00:55 | |
| *** hazmat has joined #zope3-dev | 00:56 | |
| *** ChanServ sets mode: +o hazmat | 00:56 | |
| *** RaFromBRC|lunch is now known as RaFromBRC | 00:57 | |
| *** hazmat has quit IRC | 01:05 | |
| whit | anybody know where the zc.recipe.testrunner lives? | 01:16 |
|---|---|---|
| benji | whit: it's in zc.buildout | 01:23 |
| whit | ah...thanks | 01:23 |
| benji | np | 01:23 |
| whit | is there a shorthand way to run just it? | 01:24 |
| benji | to run the testrunner? | 01:27 |
| benji | you should get a script: "bin/test" | 01:28 |
| whit | I'm not quite to the getting a script point | 01:29 |
| whit | I guess what i'm asking is how to I have buildout do that for me | 01:31 |
| *** yota has quit IRC | 01:36 | |
| *** natea is now known as natea|away | 01:37 | |
| *** jinty has quit IRC | 01:42 | |
| benji | whit: (sorry for the lag) I believe if you use the zc.recipe.testrunner recipe like this http://svn.zope.org/zc.buildout/trunk/buildout.cfg?rev=69987&view=markup you'll get a bin/test script when you run bin/buildout | 01:44 |
| whit | danke | 01:44 |
| benji | whit: this might be a better (simpler) example: http://svn.zope.org/zc.copy/trunk/buildout.cfg?rev=70009&view=markup | 01:47 |
| whit | thanks benji | 01:48 |
| benji | np | 01:48 |
| *** alecm has quit IRC | 01:50 | |
| *** natea|away has quit IRC | 01:52 | |
| *** natea has joined #zope3-dev | 01:53 | |
| *** natea has joined #zope3-dev | 01:55 | |
| *** natea is now known as natea|away | 02:19 | |
| rocky | hmm... on an IObjectModifiedEvent is there anyway to determine what fields changed? | 02:19 |
| benji | not that I know of, rocky | 02:20 |
| rocky | i have a chicken and egg problem :( | 02:20 |
| benji | is this for debugging or for actual use? | 02:20 |
| rocky | actual use | 02:21 |
| benji | you could have the object keep up with it's changes and ask it (in your IObjectModifiedEvent subscriber) | 02:21 |
| rocky | on IObjectModifiedEvent being triggered during formlib edit ... and if fields x, y, and z were modified, then field foo should be updated based on those fields... but sometimes field foo itself might be directly modified, in which case i don't want to accidentally override it's value with x, y, and z | 02:21 |
| benji | s/it's/its/ | 02:21 |
| benji | oh, I don't think I'd do that with a subscriber | 02:22 |
| rocky | perhaps i'm going about this all wrong then | 02:22 |
| benji | there /should/ be some way to do that with formlib, but I don't know enough about it to point you in the right direction | 02:23 |
| *** benji has quit IRC | 02:27 | |
| *** niemeyer has quit IRC | 02:38 | |
| *** alga__ has quit IRC | 03:05 | |
| *** niemeyer has joined #zope3-dev | 03:09 | |
| *** J1m has quit IRC | 03:12 | |
| *** markup_ has quit IRC | 03:32 | |
| *** wrobel has quit IRC | 03:33 | |
| *** niemeyer has quit IRC | 03:33 | |
| *** wrobel has joined #zope3-dev | 03:34 | |
| philiKON | rocky, yes, there is a way | 04:10 |
| philiKON | notify(ObjectModifiedEvent(obj, Attributes(ISample, "field"))) | 04:12 |
| philiKON | that indicates that the ISample(obj).field property has changed for obj | 04:12 |
| philiKON | ISample(obj) may be an adapter, it may be obj itself | 04:12 |
| philiKON | so, you'd also use ObjectModifiedEvent for things like IZopeDublinCore properties, when those change | 04:13 |
| * philiKON zzZzzZZzz | 04:15 | |
| *** philiKON has quit IRC | 04:15 | |
| *** projekt01 has left #zope3-dev | 04:29 | |
| *** RaFromBRC has quit IRC | 04:56 | |
| *** natea|away has quit IRC | 06:14 | |
| *** natea has joined #zope3-dev | 06:16 | |
| *** runyaga has joined #zope3-dev | 06:27 | |
| * runyaga smiles | 06:27 | |
| *** batlogg has joined #zope3-dev | 06:59 | |
| *** baijum has joined #zope3-dev | 07:08 | |
| *** stub has joined #zope3-dev | 07:18 | |
| *** runyaga is now known as run|away | 07:44 | |
| *** batlogg has quit IRC | 07:46 | |
| *** batlogg has joined #zope3-dev | 07:58 | |
| *** yota has joined #zope3-dev | 08:04 | |
| *** jukart has joined #zope3-dev | 08:08 | |
| *** eins has joined #zope3-dev | 08:14 | |
| *** zagy has joined #zope3-dev | 08:17 | |
| *** oferw has joined #zope3-dev | 08:24 | |
| *** natea has quit IRC | 08:37 | |
| *** alecm has joined #zope3-dev | 08:49 | |
| *** oferw has quit IRC | 08:51 | |
| *** zagy has joined #zope3-dev | 08:54 | |
| *** BjornT has quit IRC | 08:59 | |
| *** d2m has joined #zope3-dev | 09:04 | |
| *** BjornT has joined #zope3-dev | 09:24 | |
| *** philiKON has joined #zope3-dev | 09:36 | |
| *** romanofski has joined #zope3-dev | 09:38 | |
| romanofski | moin | 09:39 |
| philiKON | moin | 09:39 |
| *** dobee has joined #zope3-dev | 09:45 | |
| *** mexiKON has joined #zope3-dev | 09:54 | |
| *** BjornT___ has joined #zope3-dev | 10:00 | |
| *** philiKON has quit IRC | 10:02 | |
| *** kobold has joined #zope3-dev | 10:04 | |
| *** hdima has joined #zope3-dev | 10:06 | |
| *** MJ has quit IRC | 10:18 | |
| *** mexiKON has quit IRC | 10:33 | |
| *** BjornT__2 has joined #zope3-dev | 10:46 | |
| *** BjornT has quit IRC | 10:47 | |
| *** BjornT___ has quit IRC | 10:48 | |
| *** BjornT__ has joined #zope3-dev | 10:48 | |
| *** BjornT__ has quit IRC | 10:50 | |
| *** BjornT has joined #zope3-dev | 10:50 | |
| *** alecm has quit IRC | 10:51 | |
| *** MJ has joined #zope3-dev | 11:05 | |
| *** timte has joined #zope3-dev | 11:28 | |
| *** romanofski has quit IRC | 11:31 | |
| *** romanofski has joined #zope3-dev | 11:32 | |
| *** philiKON has joined #zope3-dev | 11:33 | |
| *** ignas has joined #zope3-dev | 11:42 | |
| *** projekt01 has joined #zope3-dev | 11:59 | |
| *** faassen has joined #zope3-dev | 12:22 | |
| *** MJ has quit IRC | 12:25 | |
| flox | zope.modulealias: "This package has been deprecated as of 2004/02/24 and will be removed after 12 months." | 12:26 |
| *** MJ has joined #zope3-dev | 12:27 | |
| flox | i guess i can remove dependency of zope.app on this module (for the /trunk, of course) | 12:27 |
| philiKON | flox, i think the date is supposed to be 2006/02/24 | 12:28 |
| *** ignas has quit IRC | 12:28 | |
| flox | ok | 12:28 |
| philiKON | flox, yup, just confirmed | 12:29 |
| philiKON | date should be 2006/... | 12:29 |
| philiKON | we can't lift the dependency on it in zope.app until it's removed | 12:30 |
| flox | so we keep the line <include package="zope.modulealias" file="meta.zcml" /> in "/zope/app/meta.zcml" | 12:30 |
| philiKON | yes | 12:30 |
| flox | ok | 12:30 |
| flox | np | 12:30 |
| flox | i commit a change for the deprecation date, ok? | 12:31 |
| philiKON | yes pelase | 12:31 |
| *** projekt01 is now known as projekt01_ | 12:35 | |
| *** Aiste has quit IRC | 12:38 | |
| *** jinty has joined #zope3-dev | 12:48 | |
| *** volvox has joined #zope3-dev | 12:58 | |
| *** Aiste has joined #zope3-dev | 13:01 | |
| *** ignas has joined #zope3-dev | 13:06 | |
| *** volvox has quit IRC | 13:24 | |
| *** volvox has joined #zope3-dev | 13:24 | |
| *** ignas_ has joined #zope3-dev | 13:28 | |
| *** ignas has quit IRC | 13:29 | |
| *** ignas_ has quit IRC | 13:29 | |
| *** ignas_ has joined #zope3-dev | 13:30 | |
| *** dobee has quit IRC | 13:32 | |
| *** mkerrin has joined #zope3-dev | 13:49 | |
| *** jhauser has joined #zope3-dev | 14:04 | |
| philiKON | flox, btw, you can put zcml:condition on the tag itself | 14:06 |
| philiKON | <browser:layer zcml:condition /> | 14:06 |
| philiKON | no need to wrap it in a configure element | 14:06 |
| philiKON | flox, ayt? | 14:13 |
| *** ofer has joined #zope3-dev | 14:14 | |
| flox | yes, i am here | 14:16 |
| flox | i was looking for visual studio :-~ | 14:16 |
| flox | bec i realize i need to have a build environment | 14:17 |
| *** dobee has joined #zope3-dev | 14:17 | |
| philiKON | flox, i have some comments about your changes | 14:17 |
| philiKON | i'm writing an email | 14:17 |
| flox | ok | 14:18 |
| flox | i do not see where i hv problem on the first commit (70042） | 14:19 |
| philiKON | flox, sent | 14:22 |
| philiKON | flox, are you running unit + functionanl tests? | 14:22 |
| flox | i am on Windows, i hv problem running such tests directly on the 'checkout' | 14:22 |
| philiKON | our policy is that all tests need to pass before you check in | 14:23 |
| philiKON | i know you can run tests from a checkout | 14:23 |
| philiKON | on windows | 14:23 |
| philiKON | because other z3 developers do it as well | 14:23 |
| philiKON | flox, i think you need to install the .pyd files | 14:23 |
| flox | i have to figure out how i do that | 14:23 |
| philiKON | http://www.zope.org/Products/Zope3 | 14:23 |
| philiKON | yes | 14:24 |
| philiKON | flox, also, see my email about discussing bigger changes like that first | 14:24 |
| flox | i see | 14:25 |
| flox | i was trying to lower the dependencies between packages | 14:28 |
| flox | just in case someone want to get rid of deprecated packages | 14:28 |
| flox | next time, i will consider twice before to commit... | 14:30 |
| philiKON | don't consider | 14:31 |
| philiKON | a) write proposal for bigger changes | 14:31 |
| philiKON | b) run tests | 14:31 |
| philiKON | we need to pick our battles | 14:32 |
| philiKON | "just in case someone wants to do X" is not good enough, really | 14:32 |
| philiKON | if you have a use case, that's fine | 14:32 |
| philiKON | but it seems like you don't | 14:32 |
| philiKON | flox, if you want to help with zope 3, you could fix some bugs :) | 14:33 |
| flox | :-) | 14:35 |
| flox | i do not see many bugs on 3.3 release, these days.. | 14:35 |
| flox | i go to lunch. bye | 14:39 |
| *** stub has quit IRC | 15:17 | |
| *** flox has quit IRC | 15:26 | |
| MJ | srichter: ayt? | 15:28 |
| srichter | yep | 15:28 |
| MJ | srichter: you need to check up with philiKON here on those layers :) | 15:28 |
| *** ktwilight has quit IRC | 15:28 | |
| MJ | srichter: See http://www.zope.org/DevHome/Wikis/DevSite/Projects/ComponentArchitecture/SimplifySkinning, I don't think that the BB is a bug.. ;) | 15:28 |
| MJ | BBB even | 15:28 |
| philiKON | MJ, ? | 15:28 |
| philiKON | ah, i see srichter 's post | 15:29 |
| *** natea has joined #zope3-dev | 15:29 | |
| * philiKON replies | 15:29 | |
| srichter | huh, layers are really deprecated for the page directive? | 15:30 |
| philiKON | who said that? | 15:30 |
| srichter | ok, are we referring to different things? | 15:30 |
| philiKON | that looks like it :) | 15:30 |
| srichter | APIDOC says so based on an E-mail I got and just replied to and I thought you guys were referring to. | 15:31 |
| philiKON | srichter, wait, i know | 15:31 |
| philiKON | LayerField is deprecated | 15:31 |
| philiKON | not the layer attribute | 15:31 |
| philiKON | once layerField is removed, it will be an InterfaceField | 15:31 |
| srichter | ok, so APIDOC shows this incorrectly, because I bet it uses the layer field still | 15:31 |
| srichter | BBB must be done different for those cases | 15:32 |
| philiKON | well, it's not apidoc's fault, i guess | 15:32 |
| philiKON | LayerField has a BBB docstring | 15:32 |
| srichter | right, so that approach is a bit too simplistic... I do not have an idea what to do instead though | 15:32 |
| MJ | maybe the BBB warning should be moved out of the docstring? | 15:32 |
| MJ | Make it a comment with the object? | 15:32 |
| philiKON | yes, that's what i did initially | 15:33 |
| philiKON | somebody added the BBB docstring | 15:33 |
| philiKON | of course, that somebody didn't add a good explanation | 15:33 |
| philiKON | which is what i usually do in user-relevant texts | 15:33 |
| philiKON | such as deprecationwarnings | 15:33 |
| philiKON | or docstrings | 15:33 |
| philiKON | so either move the BBB out o fthe docstring, or extend the docstring | 15:33 |
| srichter | ok, I would remove it | 15:34 |
| srichter | because we are *not* deprecating the layer field as such | 15:34 |
| philiKON | yup | 15:34 |
| * philiKON is out of check in range | 15:35 | |
| *** ktwilight has joined #zope3-dev | 15:39 | |
| *** flox has joined #zope3-dev | 15:41 | |
| *** ignas_ has quit IRC | 15:42 | |
| *** torkel_ has joined #zope3-dev | 15:44 | |
| *** faassen has quit IRC | 15:49 | |
| *** benji has joined #zope3-dev | 15:58 | |
| *** baijum has quit IRC | 16:02 | |
| *** ignas has joined #zope3-dev | 16:23 | |
| *** gumpa has joined #zope3-dev | 16:40 | |
| *** ofer has quit IRC | 16:43 | |
| *** tarek has joined #zope3-dev | 16:44 | |
| *** batlogg has quit IRC | 16:44 | |
| *** dobee has quit IRC | 16:52 | |
| *** dobee has joined #zope3-dev | 17:04 | |
| *** hdima has quit IRC | 17:04 | |
| *** dobee has quit IRC | 17:08 | |
| *** eins has quit IRC | 17:08 | |
| ignas | is there a way to override ++resource++ thingie used in tal templates ? | 17:15 |
| flox | philiKON: i changed zope.testrecorder, to remove dependency on zope.app.layers | 17:18 |
| *** philiKON has quit IRC | 17:19 | |
| ignas | as i want to see the exact code that generates the foo/@@/some-image.png urls | 17:20 |
| ignas | and plug into that machinery | 17:20 |
| srichter | ignas: it is a namespace as far as I know, so you can override that | 17:21 |
| flox | ignas: see zope.traversing.namespace | 17:21 |
| srichter | ignas: but I would strongly argue against plugging into this, because you make a non-compatible change | 17:21 |
| ignas | non-compatible with what? | 17:22 |
| srichter | well, then it becomes hard to talk to other people | 17:23 |
| srichter | because you have your own thing | 17:23 |
| ignas | i see | 17:23 |
| ignas | the problem is that i have navigation data stored in url like http://schooltool/+calendar/2001-01-01/daily/persons/peter | 17:24 |
| ignas | at the moment http://schooltool/+calendar/2001-01-01/daily/@@/tab.png works | 17:24 |
| ignas | but i would rather have resource urls generated without including navigation data in the url | 17:24 |
| srichter | I am really surprised this is done | 17:25 |
| ignas | i have hooked in into IAbsoluteURL for schooltool app | 17:26 |
| srichter | because resource URLs should be based on the site, which is schooltool in this case | 17:26 |
| ignas | and resources are using it to get the url | 17:26 |
| srichter | if you say "context/++resource++/tab.png/absolute_url" you will always get "nearestsite/@@/table/png" | 17:26 |
| srichter | why are you hooking into IAbsoluteURL? | 17:27 |
| ignas | so that navigation data would be stored in the url without changing all the tal templates, or code of the application | 17:27 |
| srichter | ignas: the goal of schooltool should be to become much more of a standard Zope 3 app, not less ;-) | 17:27 |
| ignas | the goal of schooltool is to become more usable for teachers/students not to become more standard ;) | 17:28 |
| srichter | ignas: I would strongly advise against that | 17:28 |
| srichter | ignas: then forget building a community around it | 17:28 |
| ignas | the change is not that harash | 17:29 |
| srichter | ignas: while your approach is very REST friendly, I think it is impractical | 17:29 |
| srichter | storing the state is a session would be the easiest | 17:29 |
| srichter | the second solution I would suggest is to use a pluggable traverser | 17:29 |
| srichter | this way you need no hooks into the existing setup | 17:29 |
| ignas | i am using a pluggableTraverser | 17:30 |
| ignas | but to put the data into URL i have to modify absolute urls | 17:30 |
| ignas | i think modifying urls is way more convenient for the user | 17:30 |
| ignas | as he can use bookmarks | 17:31 |
| ignas | else the application would become more like gmail | 17:31 |
| srichter | I do not see why you have to hook into that | 17:31 |
| srichter | we have recently used pluggable traverser to do the same thing in another project | 17:31 |
| ignas | same thing being ? | 17:31 |
| srichter | using pluggable traversers to describe menu state | 17:32 |
| ignas | you mean adding fake objects into the __parent__ __name__ stack | 17:32 |
| srichter | anyways, your design decision; though soon noone will be able to help you here anymore, because it is not what everyone else is doing | 17:32 |
| srichter | you do not have to fake anything | 17:32 |
| srichter | each traversal step represents a resource, so you can create a proxy object for it | 17:33 |
| ignas | how do your urls look like ? | 17:33 |
| srichter | for example | 17:33 |
| srichter | all items of the system are in: | 17:33 |
| srichter | http://host/items/ | 17:34 |
| srichter | it is a regular container | 17:34 |
| srichter | I now want a list of all of my items and get the list overview | 17:34 |
| srichter | http://host/myitems/list.html | 17:34 |
| srichter | So the main tab "My Items" can be selected and the sub-tab "List" is selected | 17:35 |
| srichter | of course we are using viewlets for the menu | 17:35 |
| *** alecm has joined #zope3-dev | 17:38 | |
| ignas | this concept adapted to the requirements i have might work | 17:40 |
| ignas | while it would be more complex on the programming side | 17:41 |
| srichter | ignas: I know your requirements, so I know it works :-) | 17:41 |
| ignas | as navigation data would be easier to lose, while it would be definitely more standard | 17:41 |
| srichter | maybe you can make some custom ZCML directives and base classes to help you out | 17:42 |
| ignas | these are code and complexity too | 17:42 |
| ignas | the state stored this way is very easy to loose ... especially when you have 2/3 of the application is working in another way | 17:42 |
| srichter | but one written and tested, it is hidden complexity, instead of one that is constantly around | 17:42 |
| ignas | it's not constantly around really | 17:43 |
| srichter | I think that you will find that once you converted the entire view it is much harder to loose the state than you think | 17:43 |
| srichter | ignas: I think all of ST will switch to this UI design, otherwise it si pointless and confusing | 17:44 |
| srichter | (I was there when the UI changes were discussed.) | 17:44 |
| ignas | it will, in a few months | 17:44 |
| ignas | why do you think having site absolute url modified is such a bad thing ? | 17:45 |
| srichter | it is just a feeling really; it touches too many existing well-working components | 17:46 |
| srichter | thus providing a risk of having unexpected behavior | 17:46 |
| srichter | and having the state stored at the end of the URL feels more natural to me | 17:46 |
| ignas | with a traverser that eats navigation data and returns the site on the last step it is not touching anything really | 17:46 |
| srichter | well, as I said, it's more of a feeling, but clearly with you having questions about it and having this resource issue is a sign for me that I am right :-) | 17:47 |
| ignas | :) | 17:47 |
| ignas | the problem appeared when i tired to make the default context change from the application to something else | 17:47 |
| ignas | i would have different but hard problems if i would try to make site root give out different objects every time too | 17:48 |
| ignas | i just wanted to not have the /persons/manager/ part in the url | 17:48 |
| ignas | not depending on where is the navigation data after it or before it | 17:49 |
| ignas | as I gather that it will not be actually possible to switch the context with the new style navigation | 17:49 |
| ignas | calendar tab will always point to your calendar | 17:49 |
| srichter | right | 17:50 |
| srichter | I think that .../calendar/2006-09-08/daily is nice and has all the state you need | 17:52 |
| srichter | Viewlets provide you with the flexibility you need here | 17:52 |
| srichter | the fun thing about viewlet managers is that they can look at parents and whatever to make their decision which viewlet to display and highlight | 17:52 |
| ignas | i didn't really need any viewlets, ok maybe 1 content provider that allows you to display/change navigation data | 17:53 |
| srichter | you should really become comfortable with them :-) | 17:59 |
| srichter | for any advanced UI, menus just don't cut it | 17:59 |
| ignas | what menus :D | 17:59 |
| srichter | I would have one viewlet manager for the main and the sub tab menu | 18:00 |
| ignas | as for the xomplexity of my changes - the most complex bit was modifying the navigation data in views - creating a url that would keep the mode and tab components while changing the date etc. | 18:00 |
| *** faassen has joined #zope3-dev | 18:00 | |
| srichter | I use that pattern in another app and it works wonderfully, because the menu is totally independent of the context | 18:00 |
| ignas | pretty much all of the structural changes went into http://source.schooltool.org/trac/browser/branches/schooltool-navigation-redesign/src/schooltool/skin/navigation.py | 18:01 |
| ignas | by the way did you know that zc datewidget doesn't really work with virtual hosting | 18:04 |
| ignas | at least in schooltool | 18:04 |
| ignas | as it accesses resources using "/@@/zc.datetimewidget/datetimewidget.js" instead of the full URL | 18:04 |
| faassen | ignas: that might be a zc.resourcelibrary issue then? | 18:05 |
| ignas | maybe, vidas was working on it and he said that he could not find the place where these urls are generated | 18:05 |
| faassen | ignas: I'm not sure whether zc.datetimewidget is using the resourcelibrary but it's a good chance. were they <link> urls in the HTML head> | 18:06 |
| faassen | ignas: as zc.resourcelibrary does put them in | 18:06 |
| ignas | and they assume that the application will not be hosted in a server under some directory like http://vidas.pov.lt/st-live/ | 18:06 |
| ignas | yes they were <link> urls | 18:06 |
| faassen | hm, that sucks. | 18:06 |
| faassen | http://svn.zope.org/zc.resourcelibrary/trunk/src/zc/resourcelibrary/publication.py?rev=69889&view=auto | 18:07 |
| faassen | is where the links get put in. | 18:07 |
| faassen | you'd think it would work as it should be getting the site root's URL. | 18:08 |
| faassen | site = getSite() baseURL = str(getMultiAdapter((site, self._request), IAbsoluteURL)) | 18:08 |
| ignas | indeed | 18:09 |
| faassen | anyway, hopefully that helps you. zc.resourcelibrary is actually quite useful. | 18:09 |
| faassen | because you don't have to worry about including links in your own pages anymore. | 18:09 |
| faassen | they just get included when you need them, say, somewhere deep inside a widget. | 18:09 |
| ignas | well zc.library egg 0.5.1 seems to not have the part that adds base_url | 18:11 |
| faassen | aah. | 18:11 |
| faassen | so this was a later bugfix | 18:11 |
| ignas | and that file hasn't got it's svn tags set up properly :P | 18:11 |
| faassen | yes, three weeks ago. | 18:12 |
| faassen | which file? | 18:12 |
| faassen | what do you mean with svn tags set up properly? | 18:12 |
| ignas | as svn revision headers $Id$ | 18:12 |
| ignas | are the same on both of them | 18:12 |
| faassen | you mean it doesn't have revision header replacements? | 18:12 |
| ignas | yes, wrong word | 18:12 |
| faassen | anyway, so the fix would be to pull a new egg of zc.resourcelibrary, most likely. :) | 18:13 |
| ignas | keywords | 18:13 |
| ignas | not tags | 18:13 |
| ignas | faassen: where is the version set and which one is the most up to date ? | 18:13 |
| *** zagy has quit IRC | 18:13 | |
| faassen | ignas: what do you mean? | 18:14 |
| ignas | np, just saw that it is tagged as 0.5.2 | 18:14 |
| faassen | the latest release appears to be 0.5.2 | 18:14 |
| faassen | right. | 18:14 |
| faassen | ignas: oh, I see some schooltool packages made it into ZPL land? | 18:15 |
| faassen | ignas: like the pluggable traversers bit. | 18:16 |
| ignas | oh, cool :) | 18:16 |
| faassen | ignas: didn't know we'd gotten permission to relicense that stuff. | 18:16 |
| faassen | ignas: there's some useful stuff, though a bit underdeveloped, for local utility registration, in schooltool.utility | 18:16 |
| faassen | there's so much cool stuff in that svn.zope.org now. :) | 18:17 |
| ignas | srichter: i will seriously look into the moving of navigation data to the end of the url to avoid touching of the absolute url adapter | 18:18 |
| ignas | though probably i'll have to postopone the migration at the moment | 18:19 |
| ignas | maybe i should just leave a string component in the url just to keep the part "site url should point to the site". Would it make sense to have a traversal step from application that would point to the currently logged in user ? | 18:24 |
| srichter | ignas: Fielding would say that pointing to the current user is unrestive :-) | 18:30 |
| srichter | your approach with putting the state into the URL is more appropriate | 18:31 |
| *** jukart has quit IRC | 18:36 | |
| *** J1m has joined #zope3-dev | 18:47 | |
| faassen | J1m: hey | 18:48 |
| faassen | J1m: I'm thinking about buildout a bit more, do you have time to hear some thoughts? | 18:49 |
| *** markup_ has joined #zope3-dev | 18:55 | |
| faassen | oh, I see you already thought about it (of course) | 18:56 |
| faassen | J1m: I'm having an application that wants to install instances. I have the opportunity to write the instance creation logic as part of the recipe. | 18:56 |
| faassen | J1m: but that means the instance creation logic is actually in the recipe and the application becomes a library. | 18:57 |
| faassen | J1m: and I wonder what that means. Like, a config file template would go into the recipe. | 18:58 |
| *** zagy has joined #zope3-dev | 18:58 | |
| faassen | though I imagine eggs have a way to store data. | 18:58 |
| faassen | and to maintain the code? hm. | 19:01 |
| *** xenru has joined #zope3-dev | 19:01 | |
| *** MJ has quit IRC | 19:03 | |
| *** schwendinger has quit IRC | 19:16 | |
| *** projekt01_ is now known as projekt01 | 19:20 | |
| *** alecm has quit IRC | 19:23 | |
| *** schwendinger has joined #zope3-dev | 19:27 | |
| J1m | faassen: I'm here now | 19:27 |
| faassen | J1m: okay, I'm still pondering issues. | 19:28 |
| J1m | so, obviously, the zope3instance recipe creates instances. | 19:28 |
| faassen | J1m: basically I have a situation much like the zope 3 library (which theoretically could become an egg/eggs, even though now you have a z3checkout recipe) | 19:28 |
| J1m | It's logical, in my mond, to treat instances as parts. | 19:28 |
| faassen | J1m: and an instance. | 19:28 |
| faassen | in your mond? | 19:29 |
| faassen | oh, mind. | 19:29 |
| faassen | yeah, sure. | 19:29 |
| J1m | sorry | 19:29 |
| faassen | anyway, let me sketch out the situation first. | 19:29 |
| faassen | I mean, it's analogous, but simpler and more difficult at the same time as I don't have something like a mkzopeinstance script yet. | 19:29 |
| faassen | so, I install the package as an egg. | 19:30 |
| faassen | but then I want to make an instance for this package. | 19:30 |
| faassen | this has a bin dir, a log dir, an etc dir with config files, and a var dir. | 19:30 |
| faassen | so very much like a zope 3 instance. | 19:30 |
| faassen | so what I could do is write a recipe that make all that, dumping the default config file in there, etc. | 19:30 |
| faassen | I started doing that, but I started thinking about where I want to keep the 'skeleton' | 19:31 |
| faassen | and then there's also the facility eggs provide for script entry points. | 19:31 |
| faassen | and package data. but this isn't really package data. | 19:31 |
| faassen | does one maintain the skeleton for an instance inside the recipe? | 19:31 |
| d2m | srichter: http://localhost:80808/++apidoc++/Code/zope/formlib/ is missing tests, ftest and page from the listing -- do you need a mail to mailing list ? | 19:31 |
| J1m | remond me to mention our experience with the various instance directories. :) | 19:32 |
| faassen | what about the use case of running the instance from the checkout directly? I'm doing that now. | 19:32 |
| J1m | remind | 19:32 |
| faassen | J1m: you like typing mond instead of mind today. :) | 19:32 |
| faassen | J1m: anyway, so I was wondering what way to go. | 19:32 |
| faassen | J1m: when generating the instance, I'd like to plug in some stuff, like fill in some config data that I can deduce from another part. | 19:33 |
| * J1m hates skeletins | 19:33 | |
| * faassen grins. | 19:33 | |
| *** mgedmin has joined #zope3-dev | 19:33 | |
| J1m | Yeah, so a recipe may have various templates that help with generation of instance files. | 19:33 |
| faassen | and they hate us, hiding in closets and then suddenly coming out, and there are whole armies too, of these skeletons. | 19:33 |
| J1m | These can be in the recipe package. | 19:33 |
| faassen | anyway, if you hate skeletons, what would you recommend instead? | 19:34 |
| J1m | They can be much more modest than the classic zope skels. | 19:34 |
| faassen | yes, I have a pretty modest skeleton. | 19:34 |
| J1m | So first of all, Zope instances classically have way too much structure, IMO. | 19:34 |
| faassen | basically a few empty directories, and a few tiny scripts and a config file. | 19:34 |
| faassen | anyway, I do have the usecase thatI want to mess with both LD_LIBRARY_PATH | 19:35 |
| J1m | All these silly directories are just annoying. | 19:35 |
| faassen | as well as Python path. | 19:35 |
| faassen | really? | 19:35 |
| J1m | I'll come back to LD_... | 19:35 |
| J1m | Yes. | 19:35 |
| faassen | you'd recommend keeping it flat and just putting config and data in the same directory? | 19:35 |
| faassen | and log file? | 19:35 |
| faassen | and scripts. | 19:35 |
| *** romanofski has quit IRC | 19:36 | |
| J1m | Second, when we actually deplot things, our customers (meaning our SAs) want things installed in the classic Unix way. | 19:36 |
| *** romanofski has joined #zope3-dev | 19:36 | |
| J1m | They want log files in /var/run | 19:36 |
| J1m | I mean /var/log | 19:36 |
| J1m | They want pid files in /var/run | 19:36 |
| faassen | yeah, and scripts in something/bin | 19:36 |
| J1m | and so on. | 19:36 |
| J1m | Eventually, they may want me to scatter the scripts and config files too. | 19:37 |
| *** schwendinger has quit IRC | 19:37 | |
| J1m | So, in our old buildout sw, we have strategies for spreading this stuff around. | 19:37 |
| J1m | I expect to start introdcing some suppoer for this in the current buildout. | 19:37 |
| J1m | new buildout. | 19:37 |
| J1m | I expect, for example, that the buildout will grow log-directory, pid-directory, maybe even config-directory options. | 19:38 |
| faassen | anyway, one thing that bothers me a bit is that the recipe has like, *the* config file template. | 19:38 |
| J1m | where these will default to buildout subdirectories and in deployment will point to system directories. | 19:39 |
| faassen | right, that'd be useful. | 19:39 |
| J1m | I'm not sure what your point is in referring to "the" config file template. | 19:39 |
| faassen | well. it gets spread around. | 19:40 |
| faassen | the recipe knows the config file, has the basic example. | 19:40 |
| J1m | how so? | 19:40 |
| J1m | yes? | 19:40 |
| faassen | and the software, the egg, accesses it. | 19:40 |
| faassen | somehow. | 19:40 |
| faassen | what if you want to do integration tests? | 19:40 |
| J1m | No, the recipe accesses it to create the config file that the sw uses. | 19:40 |
| faassen | right. | 19:41 |
| faassen | that's true. | 19:41 |
| faassen | so what I could do is maintain a skeleton in the recipe's package | 19:41 |
| J1m | yes | 19:41 |
| faassen | so it actually comes with the egg. | 19:41 |
| faassen | and then use the egg data access API to talk to it. | 19:41 |
| faassen | and copy it into the instance dir. | 19:41 |
| J1m | yes | 19:42 |
| faassen | and modify it to push in the right config things (based on another part we already have) | 19:42 |
| J1m | yes | 19:42 |
| faassen | and also puts in the scripts, and modifies those, messing about with the Python path. | 19:42 |
| faassen | and possibly LD_LIBRARY_PATH at all, if that's possible from within a python script. | 19:42 |
| *** projekt01 has left #zope3-dev | 19:42 | |
| faassen | at all -> as well. | 19:42 |
| *** volvox has quit IRC | 19:42 | |
| J1m | I can usually use a distutils option to avoid LD_LIBRARY_PATH. | 19:43 |
| faassen | LD_LIBRARY_PATH actually needs to have added to it a directory in another art. | 19:43 |
| faassen | part. | 19:44 |
| faassen | would that be doable with a distutils option? | 19:44 |
| J1m | BTW, did you notice the zc.recipe.egg:custom recipe? | 19:44 |
| faassen | no. | 19:44 |
| J1m | Here's a sample part section that builds the spread module: | 19:44 |
| J1m | [spreadmodule] | 19:44 |
| J1m | recipe = zc.recipe.egg:custom | 19:44 |
| J1m | egg = SpreadModule ==1.4 | 19:44 |
| J1m | find-links = http://www.python.org/other/spread/ | 19:44 |
| J1m | include-dirs = ${buildout:directory}/parts/spreadtoolkit/include | 19:44 |
| J1m | library-dirs = ${buildout:directory}/parts/spreadtoolkit/lib | 19:44 |
| J1m | rpath = ${buildout:directory}/parts/spreadtoolkit/lib | 19:45 |
| J1m | 19:45 | |
| faassen | ah, okay. | 19:45 |
| J1m | So, the custom recipe lets you build an egg with custom distutils options. | 19:45 |
| faassen | ah, useful. | 19:45 |
| J1m | The rpath option lets you control where dynamic libraries get looked for, | 19:45 |
| faassen | okay, so I'd need to set rpath. | 19:46 |
| J1m | Yup | 19:46 |
| faassen | specify a custom egg for.. | 19:46 |
| faassen | hm in my case.. | 19:46 |
| faassen | hm, I wonder whether that works in my case. | 19:47 |
| J1m | In my case, I wantd the buildout to control the spread install. | 19:47 |
| faassen | I'm not actually building anything. | 19:47 |
| faassen | I have the following setup.. | 19:47 |
| J1m | And therefore, I had to tell the spreadmodule setup.py not to look on /usr/local. | 19:47 |
| faassen | an openoffice recipe, which downloads an openoffice and installs it, messing with its Python so it uses the buildout python (in the future configurable python) | 19:48 |
| faassen | and there's an oooconv egg, which contains the sources to software to drive openoffice as a server. | 19:48 |
| faassen | and then a oooconv recipe, that installs an instance of oooconv | 19:49 |
| faassen | and when the instance's script runs, the LD_LIBRARY_PATH needs to be set to some direcory in the openoffice part. | 19:49 |
| J1m | ah, so you might be stuck with hacking LD_... | 19:49 |
| J1m | too bad. | 19:49 |
| faassen | yeah. | 19:49 |
| J1m | You'll have to generate a shell script to set that. :( | 19:50 |
| faassen | setting up openoffice in server mode with Python is an enormous pain. | 19:50 |
| faassen | that's why I'm making a buildout. | 19:50 |
| faassen | yeah, I think I'll do that. | 19:50 |
| faassen | anyway, the way is reasonably clear. | 19:51 |
| faassen | thanks for thinking this through with me. | 19:51 |
| faassen | I was grasping for the right way to go about this. anyway, I'll try this out. | 19:51 |
| *** romanofski has quit IRC | 19:56 | |
| *** romanofski has joined #zope3-dev | 19:56 | |
| *** ignas has quit IRC | 19:56 | |
| *** kobold has left #zope3-dev | 20:07 | |
| d2m | srichter: http://localhost:8080/++apidoc++/Code/zope/app/traversing is missing too, looks like you are testing for deprecated modules ? is this intentional ? | 20:08 |
| nouri | faassen: Your discussion with Jim reminds me of the Shell script we had working on Wednesday or so :) | 20:11 |
| nouri | faassen: Of course it doesn't solve all problems, just noting | 20:11 |
| mgedmin | if I use defineChecker in a unit test's setUp, is there a way to undefine it in the tearDown? | 20:14 |
| *** alecm has joined #zope3-dev | 20:15 | |
| *** natea is now known as natea|away | 20:15 | |
| *** RaFromBRC has joined #zope3-dev | 20:17 | |
| *** jinty has quit IRC | 20:20 | |
| faassen | nouri: it doesn't set the LD_LIBRARY_PATH, you need to run your env script. | 20:25 |
| *** torkel_ has quit IRC | 20:25 | |
| nouri | faassen: it includes the env script, but yeah, if you want to start up the server you need env | 20:26 |
| * nouri -> dinner | 20:26 | |
| *** jukart has joined #zope3-dev | 20:37 | |
| *** zagy has quit IRC | 20:54 | |
| *** batlogg has joined #zope3-dev | 20:56 | |
| *** MJ has joined #zope3-dev | 20:58 | |
| *** schwendinger has joined #zope3-dev | 21:00 | |
| *** natea|away is now known as natea | 21:04 | |
| *** zagy has joined #zope3-dev | 21:10 | |
| *** tarek has quit IRC | 21:14 | |
| *** alga has joined #zope3-dev | 21:19 | |
| *** faassen has quit IRC | 21:42 | |
| *** mkerrin has quit IRC | 21:58 | |
| *** projekt01 has joined #zope3-dev | 22:02 | |
| J1m | mgedmin: yes | 22:11 |
| J1m | There is an undefineChecker method. | 22:11 |
| J1m | function | 22:11 |
| J1m | whatever | 22:11 |
| mgedmin | ah, thanks | 22:11 |
| mgedmin | oh, and CleanUp also cleans them | 22:14 |
| mgedmin | apparently | 22:14 |
| mgedmin | yay | 22:14 |
| * mgedmin happy | 22:14 | |
| *** jukart has quit IRC | 22:25 | |
| *** timte has quit IRC | 22:29 | |
| *** jinty has joined #zope3-dev | 22:52 | |
| *** schwendinger has quit IRC | 23:08 | |
| *** jinty has quit IRC | 23:22 | |
| *** dunny has joined #zope3-dev | 23:26 | |
| *** MJ has quit IRC | 23:36 | |
| *** MJ has joined #zope3-dev | 23:37 | |
| *** mgedmin has quit IRC | 23:44 | |
| *** ignas has joined #zope3-dev | 23:44 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!
