| srichter | th1a: what is this doctest thing about? | 00:22 |
|---|---|---|
| th1a | Basically, jelkner wants to create assignments in the form of doctests that he can put on the web. | 00:23 |
| th1a | When students write code that makes the tests pass, they've completed the assignment. | 00:23 |
| srichter | interesting | 00:24 |
| th1a | So he needs a sandbox or a safe subset of Python for ttw work. | 00:24 |
| srichter | though I think this is not necessarily good, if the tests are too low-level | 00:24 |
| th1a | I was suggesting you might be a good mentor if they can do this through Summer of Code. It pays $500! | 00:24 |
| th1a | srichter: Are you home now? | 00:24 |
| srichter | th1a: I am flying tomorrow | 00:26 |
| srichter | sure, I could metor someone | 00:26 |
| th1a | OK. :-) | 00:26 |
| srichter | th1a: I have learned a lot about real-world app coding with Zope 3 here | 00:27 |
| th1a | Well, that's good. | 00:27 |
| th1a | I assume you won't be at the meeting then. | 00:27 |
| *** didymo has joined #schooltool | 00:29 | |
| srichter | right, I will be in the air at that time | 00:30 |
| povbot | /svn/commits: * jinty committed revision 6010: | 02:06 |
| povbot | /svn/commits: Update the schooltool-minimal test as well. | 02:06 |
| *** pcardune has joined #schooltool | 03:52 | |
| *** jinty has quit IRC | 07:20 | |
| *** vidasp has joined #schooltool | 07:59 | |
| *** didymo has quit IRC | 08:09 | |
| *** Aiste has quit IRC | 09:59 | |
| *** Aiste has joined #schooltool | 11:21 | |
| *** srichter has quit IRC | 11:24 | |
| *** thisfred has joined #schooltool | 11:33 | |
| *** vidasp has quit IRC | 12:16 | |
| *** ignas has joined #schooltool | 12:55 | |
| *** mgedmin has joined #schooltool | 13:00 | |
| *** thisfred has quit IRC | 14:34 | |
| *** thisfred has joined #schooltool | 14:39 | |
| *** faassen has joined #schooltool | 15:12 | |
| *** vidasp has joined #schooltool | 15:25 | |
| th1a | hi folks. | 16:30 |
| th1a | Everyone ready for the meeting? | 16:31 |
| th1a | faassen, ignas, mgedmin? | 16:32 |
| th1a | *tap* *tap* Is this thing on? | 16:33 |
| faassen | hello. :) | 16:33 |
| th1a | Hi faassen. When do you leave for Linux Tag? | 16:33 |
| faassen | thursday morning. | 16:33 |
| ignas | hi | 16:33 |
| faassen | busy preparing for it, releasing the document library among other things. | 16:34 |
| faassen | though currently moving demographics stuff around. | 16:34 |
| th1a | Exellent. | 16:34 |
| th1a | Excellent. | 16:34 |
| faassen | oh, why excellent? :) | 16:34 |
| faassen | which bit is? :) | 16:34 |
| th1a | I'm glad you're releasing Document Library. | 16:35 |
| faassen | oh, yeah. | 16:35 |
| th1a | It is good to have more Zope 3 products in the wild. | 16:35 |
| faassen | managing all the dependencies is a pain. | 16:35 |
| th1a | There are really quite few. | 16:35 |
| faassen | so I have been writing this long installation guide. | 16:35 |
| th1a | Products, not dependencies. | 16:35 |
| faassen | don't have time to eggify everything. :) | 16:35 |
| faassen | products? | 16:35 |
| faassen | oh, yeah, I know. | 16:36 |
| th1a | We're out of sync. | 16:36 |
| faassen | there are lots of dependencies and few products. :) | 16:36 |
| faassen | yeah. :) | 16:36 |
| faassen | yes, I ported document library over to Zope 3.2, it was still on Zope 3.1 | 16:36 |
| faassen | that seemed to be fairly straightforward, though who knows what's lurking still. | 16:36 |
| th1a | Yes, the backward compatibility is not very complete in these Zope 3 releases. | 16:36 |
| th1a | But trying to be backward compatible is still a lot better than not caring at all. | 16:37 |
| faassen | actually it surprised me how easy it was. | 16:37 |
| faassen | and the trunk was pretty backwards compatible, only a few things broke in schooltool. | 16:37 |
| faassen | after that large change last week. | 16:37 |
| faassen | but of course we don't want to be spammed with 50 zillion deprecation warnings. | 16:37 |
| faassen | and getting rid of those took a while. | 16:37 |
| th1a | Yes. | 16:37 |
| faassen | anyway, I'm now working on moving the demographics changes outside of schooltool.person | 16:38 |
| faassen | into schooltool.demographics | 16:38 |
| faassen | so hopefully things become a bit more customizable. | 16:38 |
| faassen | though I hardcode schooltool's ZCML so that it creates person objects from schooltool.demographics instead of schooltool.person | 16:38 |
| * th1a notes that we've segued into faassen's update. | 16:38 | |
| faassen | yeah, well. :) | 16:38 |
| faassen | I guess. :) | 16:38 |
| th1a | Go ahead ;-) | 16:39 |
| faassen | it's just you and me anyway. :) | 16:39 |
| th1a | ignas is here. | 16:39 |
| * ignas really ? | 16:39 | |
| th1a | Keep going :-) | 16:39 |
| faassen | oh, hi ignas. :) | 16:39 |
| faassen | I hadn't seen your 'hi' before. | 16:39 |
| faassen | anyway, oh, um, right, so, deprecation stuff undeprecated. | 16:40 |
| faassen | eggs are in. | 16:40 |
| faassen | and I started checking in demographics code. | 16:40 |
| faassen | but after some "discussion" here and some thought about new customizability requirements, I'm moving it out again, into schooltool.demographics | 16:40 |
| th1a | I'm not sure if requiring changes to ZCML are "hardcoding." | 16:40 |
| faassen | I'm rearranging the ZCML so that the New Person entry in the UI creates a new person subclass. | 16:40 |
| faassen | well, once we got skins going.. | 16:41 |
| th1a | It will be even softer coding? | 16:41 |
| faassen | it should be possible to introduce another skin which registers its own New Person thing. | 16:41 |
| ignas | faassen: what do you mean "new person subclass" | 16:41 |
| faassen | well, we need different kind of person objects. | 16:41 |
| faassen | for different schools. and yet again for schoolbell. | 16:41 |
| faassen | they all share common functionality. | 16:41 |
| faassen | but they have different data associated with them. | 16:41 |
| faassen | like, different demographics requirements, no demographics at all. | 16:42 |
| ignas | faassen: stephan might be annoyed, as he worked really hard to destroy the double class hierarchy that we had before | 16:42 |
| faassen | so I figure for each deployment we have a separate skin, and we hook in a different subclass. | 16:42 |
| faassen | which assembles the bits and pieces. | 16:42 |
| faassen | what double class hierarchy? | 16:42 |
| ignas | faassen: unless i don't fully understand you | 16:42 |
| faassen | I'm not introducing two class hierarchies? | 16:42 |
| faassen | I'm just saying, you have a base Person. | 16:42 |
| faassen | and you have a USSchoolPerson | 16:42 |
| ignas | faassen: we had - schoolbell.person and schooltool.person | 16:42 |
| faassen | and a SchoolbellPerson. | 16:42 |
| faassen | which are subclasses which add bits. | 16:43 |
| faassen | as attributes or annotations. | 16:43 |
| faassen | they were not related? | 16:43 |
| faassen | I mean, if you're going to store different data on the objects. | 16:43 |
| th1a | ignas: It seems to me that the two cases are pretty different. | 16:43 |
| ignas | faassen: and srichter worked very hard to well - make them back into a single schooltool.person by using annotations | 16:43 |
| faassen | it makes sense to have different classes. | 16:43 |
| faassen | phone, brb. | 16:43 |
| Aiste | th1a: hi | 16:43 |
| th1a | Aiste: hi. | 16:43 |
| ignas | they schooltool person was oinheriting from schoolbell person and adding bits of schooltool functionality like timetables ... | 16:44 |
| Aiste | th1a: I remember seeing my name mentioned on here a few times last Friday | 16:44 |
| Aiste | want to talk about that now or after meeting? | 16:44 |
| faassen | back. | 16:44 |
| th1a | Could we do it after? | 16:44 |
| faassen | ignas: well, it'd be reversed in my idea, but you'd still have inheritance with functionality added (mostly through attributes with their own views, or annotations) | 16:45 |
| faassen | ignas: one way or another, you'd need a difference, right? | 16:45 |
| faassen | ignas: and shared functionality. | 16:45 |
| Aiste | th1a: no problem | 16:46 |
| th1a | Generally speaking, we've been pretty consistent about using adapters for this kind of thing, | 16:46 |
| faassen | you can't adapt data into being just like that. | 16:46 |
| ignas | and annotations and subscribers | 16:46 |
| faassen | we're talking about objects which store different information. | 16:47 |
| th1a | but I'm OK with not doing that for demographics. | 16:47 |
| faassen | somehow you need to distinguish the two from each other. | 16:47 |
| faassen | I can see using annotations to add new data to objects, but that isn't the only thing that needs to change. | 16:48 |
| faassen | if you have a custom schooltool setup. | 16:48 |
| faassen | if you have a custom schooltool setup, you're also going to need a different indexing of the data. | 16:48 |
| faassen | and you're going to need a different presentation of tabular data you can browse through. | 16:48 |
| th1a | Yes, that's the rub. | 16:49 |
| ignas | i see | 16:49 |
| faassen | I think that annotations are a bit too tempting sometimes. | 16:49 |
| faassen | you don't get reusability and flexibility for free if you use them. | 16:49 |
| mgedmin | so you register custom views/viewlets in addition to registering custom adapters | 16:49 |
| faassen | I mean, I can make an extension that adds a whole bunch of new annotations to an object. | 16:49 |
| mgedmin | but I see your point | 16:49 |
| faassen | I'd already get into trouble if I didn't want the DutchPersonInfo annotation but the GreekPersonInfo. | 16:49 |
| mgedmin | actually I do not see your point | 16:50 |
| faassen | well, I think it's actually simpler to use a different skin and just produce different person objects. | 16:50 |
| mgedmin | so you're advocating Person, GreekPerson and DutchPerson as different classes? | 16:50 |
| faassen | I mean, I'm sure we *can* with enough engineering and brain power make a system that does it all with adapters and annotations and viewlets. | 16:51 |
| faassen | but I don't see that as the simplest approach. | 16:51 |
| faassen | no. | 16:51 |
| mgedmin | what happens if you then want to introduce some other axis of change? NxM custom classes? | 16:51 |
| faassen | no, you use attributes. | 16:51 |
| faassen | or annotations, for that matter. | 16:51 |
| mgedmin | yes, exactly | 16:51 |
| faassen | I'm saying we produce a differnet person class for each schoolt ype we have. | 16:51 |
| th1a | Well, we're not going to write all those classes, but perhaps people in Greece and Holland will make their own. | 16:51 |
| faassen | and schoolblel. | 16:51 |
| faassen | but we reuse common bits. | 16:51 |
| mgedmin | there's little practical difference between attributes and annotations | 16:51 |
| faassen | like, PersonInfo is shared between Dutch and Belgium, okay, we share that. | 16:51 |
| mgedmin | except one is faster and more straightforward while other is more flexible | 16:52 |
| mgedmin | and less coupled | 16:52 |
| faassen | actually it's easier to have separate views on attributes too. | 16:52 |
| faassen | I think. | 16:52 |
| faassen | I mean, an annotation view is on the person object. | 16:52 |
| faassen | an attribute view can be on the attribute of the person object. | 16:52 |
| faassen | I think persons/faassen/nameinfo/edit.html can be prettier than.. | 16:53 |
| mgedmin | but then you need a custom traverser to get that attribute? | 16:53 |
| faassen | persons/faassen/nameinfo_edit.html | 16:53 |
| faassen | sure. | 16:53 |
| ignas | faassen: what i have envisioned was - using a separate module like "GreekCustomizations" that would attach required annotations/subscribers/adapters through zcml without inheriting from any of schooltool/bell classes | 16:53 |
| faassen | ignas: well, that doesn't gain you much, does it? | 16:53 |
| ignas | faassen: though it might be more difficult to implement than to envision ;) | 16:53 |
| faassen | ignas: I just don't see what it practically gains you. you still need to override views, most likely. | 16:53 |
| faassen | ignas: and we're not likely to have schools suddenly switch their database from Greek to US or something. | 16:54 |
| th1a | One important thing to remember is that what we need at this point is a quick and dirty demographics implementation that works. | 16:54 |
| faassen | ignas: annotations arguably makes evolution of content harder. | 16:54 |
| faassen | I'm arguing that this is simpler *and* better. :) | 16:54 |
| ignas | faassen: what we will have is - modification of base classes independently from custom classes | 16:54 |
| ignas | and i am afraid that it is too easy to break inheriting classes | 16:55 |
| faassen | I think annotations sound more flexible and less invasive than we are. In practice we *do* have different databases, of Greek students and Dutch students. | 16:55 |
| th1a | faassen: I agree that it is worth some experimenting at this point. | 16:55 |
| faassen | we are -> they are | 16:55 |
| ignas | anyway, implement it your way, we'll refactor it later if needed | 16:55 |
| faassen | sure. | 16:55 |
| ignas | having something working is more important now | 16:56 |
| ignas | if i understand correctly | 16:56 |
| faassen | I am positing the existence of a different skin per customization. | 16:56 |
| faassen | (probably reusing bits of existing skins) | 16:56 |
| th1a | ignas: Indeed. | 16:56 |
| faassen | anyway, the idea that inheritance is bad can be taken a bit too far. :) | 16:56 |
| th1a | OK... so I think we've exhausted that topic. | 16:57 |
| th1a | Without anyone getting shot in the face. | 16:57 |
| th1a | Shall we move on to POV's update? | 16:57 |
| faassen | yeah. :) | 16:58 |
| ignas | well, last week we've been working on resources booking conflict resolution and displaying of resources/bookers on calendars properly | 16:58 |
| ignas | which involved removal of some unnescessary complexity from schooltool | 16:59 |
| ignas | like - resource booking for independent activities, scheduling of groups/persons/resources without adding them to sections | 16:59 |
| ignas | now we am working on scheduling conflict resolution views for persons/resources | 17:00 |
| ignas | which requires some serious optimization of the view | 17:00 |
| ignas | person scheduling view | 17:00 |
| ignas | that's kind of it | 17:01 |
| th1a | Which is the "person scheduling view?" | 17:01 |
| ignas | when you go to view a person and click "Schedule" in the action menu | 17:02 |
| th1a | To assign sections to an individual student? | 17:02 |
| ignas | yes | 17:03 |
| ignas | as resource booking is functioning identically - it is a nice target for code reuse | 17:03 |
| th1a | Oh. OK. | 17:03 |
| th1a | That form needed some help anyhow. | 17:04 |
| ignas | it is way too slow though at the moment | 17:04 |
| ignas | because of some deed by our former american coleagues :/ | 17:04 |
| ignas | s/deed/deeds | 17:05 |
| th1a | Perhaps if you'd have jumped on them as quickly as you jumped on martijn we would have avoided some problems. | 17:05 |
| th1a | Anyhow... | 17:05 |
| ignas | we were jumping, but we were leaving it up to them to fix things | 17:05 |
| th1a | Water under the bridge. | 17:06 |
| faassen | hey, I was only creating faster code. :) | 17:06 |
| faassen | I was jumped on for that, or at least for not backing it up. :) | 17:06 |
| th1a | OK, so, I've got a few agenda items here. | 17:06 |
| th1a | So... building SchoolTool now. | 17:07 |
| th1a | Can I use the setuptools from dapper? | 17:07 |
| th1a | Or is that too old? | 17:07 |
| faassen | this setuptools stuff is really a pain. I heard it's going to be merged in the Python core at some stage, but that doesn't help us of course. | 17:08 |
| faassen | apparently dapper's too old. | 17:08 |
| faassen | it's fairly easy to install your own recent setuptools into your Python's location, if you're okay with "polluting" your system. | 17:08 |
| th1a | I don't have much choice. | 17:09 |
| faassen | there's info in README | 17:09 |
| faassen | http://peak.telecommunity.com/DevCenter/EasyInstall#installing-easy-install | 17:09 |
| faassen | there's an ez_setup script there, and that takes care of installing everything needed. | 17:09 |
| mgedmin | cd /tmp && wget http://peak.telecommunity.com/dist/ez_setup.py && sudo python2.4 ez_setup.py --prefix=/usr/local | 17:09 |
| mgedmin | is what I used on the buildbot slave machine | 17:09 |
| mgedmin | although downloading scripts from the interweb and running them as root is not something I like to do | 17:09 |
| faassen | no, I can imagine. | 17:10 |
| mgedmin | especially when the script in question downloads more software from the web and runs it | 17:10 |
| faassen | :) | 17:10 |
| mgedmin | (without any cryptographic verification) | 17:10 |
| faassen | can't you run that stuff as user? | 17:10 |
| faassen | maybe at some point worthwhile looking at virtual python or whatever it's called. | 17:10 |
| th1a | Actually, it would make me REALLY HAPPY if we had instructions for building from a svn checkout in the README, in addition to the source tarball instructions. | 17:10 |
| mgedmin | we could maybe ask jinty to build us a setuptools deb package with the new version of setuptools? | 17:10 |
| faassen | apparently that makes it easy to do new python installs that aren't really. | 17:10 |
| faassen | th1a: I did add such instructions, though perhaps they're hard to find? | 17:11 |
| faassen | th1a: or do you mean in general, the whole 'make' dance? | 17:11 |
| mgedmin | BTW that command that I pasted -- it ends by printing a confusing error message, but seems to work just fine after that | 17:11 |
| ignas | faassen: you can't do a dry run (a bug apparently) so you must manualy chown all the directories to the user who will run the script, run the script and chown them back, and finding out where the script will write stuff is a bit difficult without dry-run | 17:11 |
| th1a | faassen: You mean the "Egg dependencies and checkouts" section? | 17:12 |
| faassen | th1a: oh wait, my instructions are mostly when you want to check into eggs. | 17:12 |
| faassen | th1a: so that sin't really relevant. | 17:12 |
| faassen | th1a: anyway, the eggs just kick in when you do 'make' | 17:12 |
| th1a | Oh. | 17:12 |
| th1a | So if I have the right setuptools, I should just be able to do "make?" | 17:12 |
| faassen | besides all the valid complains of mgedmin and ignas, the *nice* thing is that there's just a 1 liner added to make | 17:12 |
| faassen | that pulls in the right eggs. | 17:13 |
| faassen | when you do make. | 17:13 |
| faassen | yes. | 17:13 |
| th1a | Ah. That's not so bad then. | 17:13 |
| th1a | OK. I'll work on that. | 17:13 |
| th1a | Moving on... | 17:14 |
| th1a | Are there any outstanding issues from the Zope 3 changes? | 17:14 |
| faassen | not that I know of. I need to go fix up one deprecation warning in an egg. | 17:14 |
| faassen | that should be easy, just haven't gotten around to doing so. | 17:14 |
| faassen | the utility registration is using the new system. | 17:15 |
| faassen | and I went through the whole schooltool codebase changing imports to cope with moved packages. | 17:15 |
| th1a | Cool. Thanks for doing that faassen. | 17:15 |
| faassen | well it was an easy way to actually feel productive. :) | 17:16 |
| th1a | OK then... lets talk a bit more about the SchoolBell release. | 17:16 |
| th1a | In a sense, I see this release as preparing the way to turn SchoolBell over to a volunteer maintainer. | 17:17 |
| th1a | Whether or not such a person exists. | 17:17 |
| ignas | for schoolbell | 17:17 |
| th1a | Yes. | 17:18 |
| faassen | if there's no such active maintainer, how do you deal with people breaking stuff in schoolbell when developing schoolbell? | 17:18 |
| ignas | will we ever want to run both schoolbell/schooltool as zope products | 17:18 |
| ignas | or should we just separate schoolbell as an application | 17:18 |
| th1a | I don't think mixing SchoolBell and SchoolTool on one Zope server will ever be very important. | 17:19 |
| ignas | so they can have different zcml files | 17:19 |
| th1a | Basically, someone who is using SchoolBell has to start advocating for it and maintaining it. | 17:20 |
| th1a | But before that happens, we have to bring it back to a usable state. | 17:20 |
| ignas | usable state being - scripts schooltool-server.py and schoolbell-server.py both working in the top level directory of the project ? | 17:21 |
| tiredbones | BOOKMARK | 17:21 |
| ignas | or just some setuptools magic that can package two distinct tarballs | 17:21 |
| th1a | I'm thinking two distinct tarballs. | 17:21 |
| ignas | how independent schoolbell should be ? | 17:22 |
| th1a | Basically, we need to get it to that point, and then find someone who will at least keep track of when we break SchoolBell and then work with us to keep it going. | 17:22 |
| mgedmin | nightly buildbot for schoolbell | 17:22 |
| ignas | should we strive for the perfect isolation - like schoolbell having no unnescesarry packages from schooltool | 17:22 |
| th1a | Yes, I guess a bot could do the first step ;-) | 17:23 |
| mgedmin | I think that should be a desirable goal that is not an absolute requirement | 17:23 |
| th1a | mgedmin: A agree. | 17:23 |
| th1a | Also, it depends on how far away the component is from calendaring. | 17:23 |
| ignas | timetabling, attendance, courses, sections | 17:24 |
| ignas | as timetabling is very closely related (way too closely as there are dependencies both ways) | 17:24 |
| ignas | and courses with sections both are dependencies for timetabling | 17:24 |
| th1a | Ah... | 17:24 |
| ignas | we might need considerable time to fully and cleanly decouple everything | 17:24 |
| ignas | can't tell exact numbers yet though | 17:25 |
| th1a | Shit. | 17:25 |
| th1a | Maybe we just can't pull this off. | 17:25 |
| ignas | i think it is doable | 17:26 |
| th1a | Or we just have to fake it in the UI. | 17:26 |
| mgedmin | ignas: what's your point? schooltool doesn't need timetabling/attendance/sections/courses | 17:26 |
| th1a | SchoolBell should pretty much just show "persons," "groups," "resources." | 17:26 |
| ignas | ignas: schoolbell doesn't need timetabling etc. | 17:26 |
| mgedmin | yes, but we don't need to decouple timetables from sections | 17:26 |
| ignas | th1a: i will try to give you a clear estimate as soon as i can | 17:27 |
| th1a | OK. | 17:27 |
| ignas | mgedmin: yes i know, we need to decouple timetabling from calendaring though | 17:27 |
| th1a | OTOH, having demographics in SchoolBell wouldn't make much difference. | 17:27 |
| mgedmin | that's right | 17:27 |
| ignas | th1a: yes, probably | 17:27 |
| faassen | I'm busy moving that out. :0 | 17:27 |
| th1a | I think that's the tough part. | 17:27 |
| faassen | :) | 17:27 |
| faassen | you should be able to turn on whatever is in person only.. | 17:27 |
| th1a | timetabling and calendaring. | 17:27 |
| faassen | with a bit of different ZCML. | 17:27 |
| th1a | We're about done then. | 17:28 |
| th1a | I think we've clarified some things. | 17:28 |
| th1a | Everyone happy? :-) | 17:28 |
| faassen | sure. :) | 17:29 |
| ignas | yep | 17:29 |
| th1a | OK then. | 17:29 |
| th1a | Have a good week. | 17:29 |
| faassen | th1a: thanks. | 17:29 |
| * th1a bangs the virtual bag of gravel. | 17:30 | |
| Aiste | ;) | 17:30 |
| faassen | th1a: do you know whether Mark will be at LinuxTag? I mean, more than last week? | 17:30 |
| th1a | th1a: Oh... was he there last week? | 17:31 |
| th1a | I think he was in New York over this weekend. | 17:31 |
| faassen | no, no. | 17:31 |
| faassen | I mean, do we know more than last week. | 17:31 |
| th1a | Doesn't LinuxTag mean LinuxDay? | 17:31 |
| faassen | sorry to be ocnfusing. :) | 17:31 |
| faassen | yes, I meant LinuxTag in Germany. | 17:32 |
| faassen | it's more than one day. :) | 17:32 |
| faassen | though. | 17:32 |
| th1a | No, I have no additional knowledge. | 17:32 |
| faassen | has been for years. | 17:32 |
| faassen | okay. :) | 17:32 |
| faassen | mgedmin: so, you had some ideas. | 17:32 |
| mgedmin | faassen: dependencies | 17:32 |
| faassen | mgedmin: right. | 17:32 |
| mgedmin | a story, not ideas | 17:32 |
| mgedmin | we have a bunch of precreated groups and users in ST | 17:32 |
| faassen | mgedmin: okay, tell me the story. | 17:33 |
| faassen | mgedmin: right. | 17:33 |
| mgedmin | there was a requirement to make these undeletable | 17:33 |
| mgedmin | our chosen implementation was to use the standard zope 3 dependencies framework | 17:33 |
| mgedmin | look at src/schooltool/group/group.py, def addGroupContainerToApplication | 17:33 |
| mgedmin | to make a group undeletable it uses the IDependable adapter and says that the application object depends on this group object | 17:34 |
| mgedmin | then zope prevents anyone from deleting the groups somehow | 17:34 |
| mgedmin | (I think with an event subscriber that raises exceptions) | 17:34 |
| mgedmin | and our views also check for undeletability by using IDependable | 17:34 |
| faassen | right.. | 17:35 |
| mgedmin | if you now need to delete and recreate an object in a generation script | 17:35 |
| mgedmin | you can use IDependable() | 17:35 |
| mgedmin | to remove the dependency | 17:35 |
| mgedmin | create a new object instead | 17:35 |
| mgedmin | and make it undeletable again | 17:35 |
| faassen | oh, IDependable is used to get rid of the dependency? | 17:35 |
| faassen | ther's some API on it? | 17:36 |
| mgedmin | IDependable is used to do all sorts of things with the dependencies | 17:36 |
| faassen | okay. | 17:36 |
| faassen | I shall try that. | 17:36 |
| faassen | thanks! | 17:36 |
| mgedmin | it's an adapter like IAnnotations | 17:36 |
| faassen | right. | 17:36 |
| faassen | anyway, I shall continue to think about demographics with and without annotations. :) | 17:36 |
| mgedmin | this framework is (or was) primarily used in Zope 3 to mark dependencies between local components and their registration objects | 17:36 |
| faassen | I just wanted to let you guys know that while I argue just as hard back at you guys as you argue to me.. :) | 17:36 |
| faassen | I'm actually listening too. :) | 17:36 |
| faassen | right, I knew that bit, about the local component and registration objects. | 17:37 |
| faassen | I think that's now obsolete, possibly, with the latest Zope 3 core refactoring. | 17:37 |
| faassen | though possibly not, perhaps it just puts a nicer API over it all. | 17:37 |
| mgedmin | I'm pretty sure the local component stuff has changed all over the place | 17:38 |
| faassen | mgedmin: thanks for pointing me to that code. | 17:38 |
| faassen | mgedmin: I shall check out IDependable. | 17:38 |
| mgedmin | but I think the dependency tracking package remained | 17:38 |
| ignas | faassen: as long as you don't forget that most of the things i am saying are just FYI's and warnings we'll be all right ;) | 17:38 |
| mgedmin | it's independent and quite generic | 17:38 |
| faassen | mgedmin: must have, otheriwse I wouldn't get this error. | 17:38 |
| faassen | mgedmin: you adding a dependency to '' means you want to add a dependency to the Zope 3 root, right? | 18:18 |
| mgedmin | faassen: yes, IIRC the dependency framework didn't accept '/' because it wanted a path explicitly relative to the root folder or something like that | 18:18 |
| faassen | well, either there's a bug in Zope 3's dependency framework or doing this should be illegal. | 18:19 |
| faassen | because what in effect happens is that /persons/ will become a dependency, with trailing slash. | 18:19 |
| faassen | according to dependencies() | 18:19 |
| faassen | and that's wrong, right? | 18:19 |
| faassen | and what's worse, using removeDependency() on paths in dependencies() results in an error. | 18:20 |
| faassen | as trailing slashes aren't allowed in paths and Zope complains. | 18:20 |
| faassen | and doesn't remove any dependency. | 18:20 |
| faassen | and the one thing you'd expect is this to work: | 18:20 |
| faassen | for dependency in dependable.dependencies(): | 18:20 |
| faassen | dependable.removeDependency(dependency) | 18:20 |
| faassen | sorry, removeDependent | 18:20 |
| mgedmin | hmm | 18:27 |
| mgedmin | can you do removeDependency('')? | 18:27 |
| mgedmin | I might be wrong thinking that addDep..('') means the root folder | 18:28 |
| mgedmin | it probably does mean the person container | 18:28 |
| mgedmin | still, if you can't use removeDependent with a string you got by listing all dependents, that smells like a bug | 18:29 |
| faassen | yes. | 18:40 |
| faassen | well, I'd be surprised if it means the person container. | 18:41 |
| faassen | hm, perhaps it does.. | 18:41 |
| mgedmin | I wouldn't | 18:41 |
| mgedmin | there is some reason I didn't use '/' there | 18:41 |
| mgedmin | I'm sure the system didn't allow me to do that | 18:42 |
| faassen | well, it's never made relative. | 18:42 |
| mgedmin | um... OTOH I already demonstrated today that my memory is not reliable | 18:42 |
| faassen | although.. | 18:42 |
| mgedmin | did I write that code or was it someone else? | 18:42 |
| faassen | I don't know. | 18:42 |
| mgedmin | what does svn annotate say? | 18:42 |
| faassen | you did. | 18:45 |
| faassen | but I suspect it's coming from a branch so I don't know anymore. | 18:46 |
| faassen | that's schooltool/app/main.py | 18:46 |
| *** jinty has joined #schooltool | 18:49 | |
| *** gnosis has joined #schooltool | 18:52 | |
| *** ignas has quit IRC | 19:00 | |
| faassen | argh, that whole zope.app.dependency is seriously borked. | 19:14 |
| faassen | at least for adding '', it causes dependencies taht cannot be removed anymore. :) | 19:15 |
| faassen | as far as I can see. | 19:15 |
| faassen | which is surprising.. | 19:15 |
| mgedmin | wow | 19:17 |
| faassen | I'm about to give up in disgust for today. | 19:27 |
| faassen | the dependency framework is doing things that should be centralized in Zope 3. | 19:27 |
| faassen | path manipulation. | 19:27 |
| faassen | but instead it has its own relative path stuff. | 19:27 |
| faassen | and if you enter '' it gets hopelessly confused, trying to make things absolute and relative, and back again. :) | 19:28 |
| faassen | what a frustrating little problem. | 19:28 |
| mgedmin | ouch | 19:31 |
| mgedmin | nobody would hurt you if you just accessed the storage attributes internal to the zope.app.dependency from an evolution script | 19:32 |
| mgedmin | the storage method is frozen with respect to the generation number... | 19:32 |
| faassen | true. | 19:32 |
| mgedmin | oops, but there are different parallel generation numbers | 19:32 |
| mgedmin | schooltool's one (which can be considered to be known inside a ST generation script) | 19:32 |
| mgedmin | and zope's | 19:32 |
| mgedmin | OTOH we know which zope generations were used with which ST release | 19:33 |
| mgedmin | so an ST generation number kind of implies the zope generation number... | 19:33 |
| faassen | I'm confused by all this, I thought I only needed to care aobut Schooltool's evolution scripts. | 19:33 |
| mgedmin | well, yes, I'm confused too | 19:33 |
| faassen | anyway, it's just a pain, this stupid dependency issue blocks the generation script from working. :) | 19:34 |
| mgedmin | otoh... its best when generations are really independent, I think | 19:34 |
| faassen | but yeah, I think I'll do some brute force. | 19:34 |
| faassen | and fiddle with internals. | 19:34 |
| faassen | but basically schooltool itself shouldn't use the broken '' dependencies. | 19:34 |
| faassen | or zope.app.dependency needs to be fixed. and likely that also needs evolution then, if the stored data changed. | 19:34 |
| faassen | sigh. | 19:35 |
| faassen | I think tomorrow I'll forget about all that and just re-lock them forever with '' :) | 19:35 |
| faassen | see you! | 19:36 |
| *** faassen has quit IRC | 19:36 | |
| mgedmin | faasen, if zope.app.dependency is broken, and you know in what way it is broken, you could at least file a bug report to the collector | 19:37 |
| *** jinty has quit IRC | 19:40 | |
| *** jinty has joined #schooltool | 19:43 | |
| *** thisfred has quit IRC | 19:51 | |
| povbot | /svn/commits: * gintas committed revision 6011: | 19:55 |
| povbot | /svn/commits: Optimizations in PersonTimetableSetupView. | 19:55 |
| *** Aiste has quit IRC | 20:20 | |
| povbot | /svn/commits: * gintas committed revision 6012: | 20:25 |
| povbot | /svn/commits: Renamed Timetable.itercontent() to activity(). Now it returns a list rather than an iterator, which gains us 50% speed in some cases. | 20:25 |
| *** Aiste has joined #schooltool | 21:07 | |
| *** mgedmin has quit IRC | 22:14 | |
| *** jinty has quit IRC | 23:07 | |
| *** srichter has joined #schooltool | 23:49 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!