crankd restructure, opinions sought.
Nigel Kersten
base with the odd fix.
I'm planning to switch away from /usr/bin/env python to being explicit
about python2.5 as that's the OS X python version we require.
Anyone have any objections?
I'm also unsure about the new module layout, we basically have:
/Library/Application Support/crankd/PyMacAdmin/crankd
which feels wrong.
I'm not sure I'm entirely happy with the idea of
/Library/Application Support/PyMacAdmin/crankd
though....
thoughts?
Currently there is no explicit relationship required between
PyMacAdmin and crankd. The utility methods in the PyMacAdmin module
aren't necessary at all for crankd, and I'm tempted to say that we
shouldn't require them. The stuff that is there I feel would work
better in a Carbon module or something.
The longer term goal is to simply have a package install, and I'd like
to push forward with crankd as a standalone project.
Of course I don't know for sure what was going on in Chris' head, so
may be missing the point here :)
Chris Adams
leaning towards is a mix:
1. The PyMacAdmin code goes in the standard Python locations - e.g.
/Library/Python/2.5/site-packages - as you'd get with a basic install.
The idea being that you shouldn't need to play games to get it into
the default path simply to get "import PyMacAdmin" to work and
"easy_install pymacadmin" works like other Python packages.
2. /Library/Application Support/PyMacAdmin and
$HOME/Library/Application Support/PyMacAdmin are placed into the
default python path so users can install whatever code they write
there.
3. crankd looks for its config in /Library/Preferences and
$HOME/Library/Preferences, following expected behaviour for Mac apps.
As far as a separate install goes, it's not a bad idea since crankd is
a pretty separate beast. The one catch is that I'd been planning to
separate the event handlers out to avoid having one massive .py file
but that might not be necessary with a bit of code cleanup since the
current structure is a bit suboptimal (not surprising given how
quickly it was hacked together last spring). Here's what I had in
mind:
/Library/Python/2.5/site-packages/PyMacAdmin has the entire project
/Library/Python/2.5/site-packages /PyMacAdmin/crankd/__init__.py has
some library code and each of the different event handlers could be
broken into a separate file:
/Library/Python/2.5/site-packages /PyMacAdmin/crankd/FSEvents.py
/Library/Python/2.5/site-packages /PyMacAdmin/crankd/NSWorkspace.py
etc.
The idea being that each one could inherit from a base EventSource
class (getting rid of some of the hokey duplicate code in crankd now)
and we could add some niceties for event handlers cleaning up the raw
event data before calling user code.
Thinking about this, however, it could also be done in a single large
crankd file - the biggest benefit is going to be refactoring the
existing code into smarter classes and cleaning up some of the
structural oddities which crept in along the way.
Chris
Nigel Kersten
> Thinking about this, however, it could also be done in a single large
> crankd file - the biggest benefit is going to be refactoring the
> existing code into smarter classes and cleaning up some of the
> structural oddities which crept in along the way.
Honestly, this is what I'm leaning towards.
I don't quite see that we're going to do much in crankd itself that is
worth creating a module for so other tools can use it?
Preston Holmes
On Aug 19, 2009, at 11:24 AM, Nigel Kersten wrote:
>
> So I'm working today on merging Chris' changes back into the main code
> base with the odd fix.
>
> I'm planning to switch away from /usr/bin/env python to being explicit
> about python2.5 as that's the OS X python version we require.
>
> Anyone have any objections?
If you want to assert > 2.4 - then why not just test the python
version and error if condition not met?
>
> I'm also unsure about the new module layout, we basically have:
> /Library/Application Support/crankd/PyMacAdmin/crankd
>
> which feels wrong.
>
> I'm not sure I'm entirely happy with the idea of
> /Library/Application Support/PyMacAdmin/crankd
>
> though....
>
> thoughts?
on the python path (either a virtualenv or site-packages)
It should also be renamed to pymacadmin to conform to convention (PEP 8)
>
> Currently there is no explicit relationship required between
> PyMacAdmin and crankd. The utility methods in the PyMacAdmin module
> aren't necessary at all for crankd, and I'm tempted to say that we
> shouldn't require them.
out into pymacadmin and made available to other python code in a more
abstract way.
so that one could do something like:
import pymacadmin
my_listener = pymacadmin.SystemConfigurationListener ()
def my_func(event):
print event.data
my_listener.add_event ('State:/IOKit/Power/CPUPower', my_func)
my_listener.start()
My own attempts at such a refactor got mired in thread and runloop
issues, lack of time, lack of familiarity of Carbon
I do think it would be possible - a SystemConfigurationListener object
would just maintain its own NSThread and NSRunloop - but it will be
tricky and I doubt anyone has time to mess with it.
-Preston
Preston Holmes
On Aug 19, 2009, at 12:04 PM, Nigel Kersten wrote:
> I don't quite see that we're going to do much in crankd itself that is
> worth creating a module for so other tools can use it?
I'm not sure I agree. I think having the event listening code
available to python projects outside of crankd would be valuable.
The biggest issue with using crankd from within python right now is
that to have your python function called in response to an event, it
has to resolve from a string to something on the python path. This
makes it harder to harness crankd functionality from various projects
The sticky part is the runloop - its simple to have everything in one
place with one runloop. The timer hack to keep the runloop responsive
could be avoided (in the Dev Docs it says to avoid this technique) if
each event watched for had its own thread and runloop. Each thread
would lay quiet until the event happened and then callback into python
code.
However I think all of the above comes after some cleanup work to
crankd - since it is a major change and involves tricky interaction of
NSThreads and python code.
-Preston
Nigel Kersten
On Wed, Aug 19, 2009 at 12:20 PM, Nigel Kersten<ni...@explanatorygap.net> wrote:
>>
>>
>> On Aug 19, 2009, at 11:24 AM, Nigel Kersten wrote:
>>
>>>
>>> So I'm working today on merging Chris' changes back into the main code
>>> base with the odd fix.
>>>
>>> I'm planning to switch away from /usr/bin/env python to being explicit
>>> about python2.5 as that's the OS X python version we require.
>>>
>>> Anyone have any objections?
>>
>> What is gained? This will mess with any use in a Python virtualenv
>
> env, particularly in environments like Mac OS X where you can have a
> bunch of completely different python interpreters installed.
>
> It breaks killall, it makes process listings annoying, and I heartily
> dislike having a target that isn't explicit.
>
> It's difficult to find dependencies when trawling through masses of python code.
>
> Do we really want to supply a package of crankd where if someone
> pre-pends say the fink/MacPorts path to their PATH it breaks crankd
> completely? That just seems like a bad idea to me.
>
> Personally we don't use env at all at Google, I have users with tens
> of different python interpreters installed, and I'd be patching crankd
> to change this every time.
>
>>
>> If you want to assert > 2.4 - then why not just test the python
>> version and error if condition not met?
>
> Python 2.6 on this computer that crankd can't work with.
>
>>
>>>
>>> I'm also unsure about the new module layout, we basically have:
>>> /Library/Application Support/crankd/PyMacAdmin/crankd
>>>
>>> which feels wrong.
>>>
>>> I'm not sure I'm entirely happy with the idea of
>>> /Library/Application Support/PyMacAdmin/crankd
>>>
>>> though....
>>>
>>> thoughts?
>>
>> PyMacAdmin should be migrated to be a regular python package installed
>> on the python path (either a virtualenv or site-packages)
>>
>> It should also be renamed to pymacadmin to conform to convention (PEP 8)
>
> structures to PEP 8. We can't just follow PEP 8 unfortunately, but we
> should where we can.
>
> I just don't think pymacadmin is a very good name for a module.
>
>>
>>
>>>
>>> Currently there is no explicit relationship required between
>>> PyMacAdmin and crankd. The utility methods in the PyMacAdmin module
>>> aren't necessary at all for crankd, and I'm tempted to say that we
>>> shouldn't require them.
>>
>> I do think that, ideally, the main areas of crankd should be factored
>> out into pymacadmin and made available to other python code in a more
>> abstract way.
>>
>> so that one could do something like:
>>
>> import pymacadmin
>>
>> my_listener = pymacadmin.SystemConfigurationListener ()
>>
>> def my_func(event):
>> print event.data
>>
>> my_listener.add_event ('State:/IOKit/Power/CPUPower', my_func)
>>
>> my_listener.start()
>>
>> My own attempts at such a refactor got mired in thread and runloop
>> issues, lack of time, lack of familiarity of Carbon
>>
>> I do think it would be possible - a SystemConfigurationListener object
>> would just maintain its own NSThread and NSRunloop - but it will be
>> tricky and I doubt anyone has time to mess with it.
>
> some point later it would be great to do all this work, but I don't
> see it happening now.
Preston Holmes
(groups having issues. re-sending)
What is gained? This will mess with any use in a Python virtualenvI'm not going to put up a huge fight on this, but I'm totally againstenv, particularly in environments like Mac OS X where you can have abunch of completely different python interpreters installed.
If you want to assert > 2.4 - then why not just test the pythonversion and error if condition not met?Because it's not just the version that matters. I have an install ofPython 2.6 on this computer that crankd can't work with.
PyMacAdmin should be migrated to be a regular python package installedon the python path (either a virtualenv or site-packages)It should also be renamed to pymacadmin to conform to convention (PEP 8)Cocoa and PyObjC dictate completely different method names and classstructures to PEP 8. We can't just follow PEP 8 unfortunately, but weshould where we can.I just don't think pymacadmin is a very good name for a module.
Nigel Kersten
>
> On Aug 19, 2009, at 12:29 PM, Nigel Kersten wrote:
>
> (groups having issues. re-sending)
>
>
> What is gained? This will mess with any use in a Python virtualenv
>
> I'm not going to put up a huge fight on this, but I'm totally against
>
> env, particularly in environments like Mac OS X where you can have a
>
> bunch of completely different python interpreters installed.
>
> I have no particular objection to the hard target - crankd is very platform
> obligate. But this is why some other python projects are moving to the
> virtualenv model - it is the best way to ensure a consistent runtime env for
> python.
>
>
> If you want to assert > 2.4 - then why not just test the python
>
> version and error if condition not met?
>
> Because it's not just the version that matters. I have an install of
>
> Python 2.6 on this computer that crankd can't work with.
>
> Well I don't know the details, but it seems that anything that isn't forward
> compatible through < 3.x could/should be considered a bug.
nigelk$ /opt/local/bin/python2.6 -c "import Cocoa"
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named Cocoa
nigelk$ /usr/bin/python2.5 -c "import Cocoa"
nigelk$
see? crankd has explicit dependencies upon *Apple*'s python2.5
Nigel Kersten
>> But as a python module not a Cocoa Library its first citizenship is Python
>> I agree about pymacadmin - if it is a python module, the py part is
>> redundant. I'd be happy with macadmin or madmin (others off the top of my
>> head: macsystools, mactools)
I forgot to address this.
I really just dislike general purpose names altogether, and would
rather see us come up with several decent modules that are targeted at
certain functionality rather than bundling everything into a
macadmin/madmin/mactools module.
This is somewhat orthogonal to this discussion as far as getting a
packageable version of crankd out there for people.
Greg Neagle
-Greg
Chris Adams
> I really just dislike general purpose names altogether, and would
> rather see us come up with several decent modules that are targeted at
> certain functionality rather than bundling everything into a
> macadmin/madmin/mactools module.
I'm entirely comfortable just using PyMacAdmin as a google-friendly
project / repository name and distributing more granular packages. I
think there's value in having e.g. the entire collection of
Cocoa/Carbon-bridge wrappers under lib sharing code since there's at
least some utility overlap (e.g. the carbon error handling code) but
the image unit testing framework and crankd have nothing in common
with each other or those libraries.
Chris