Is there a way to do this?
-Greg
I've yet to work out a good code review process with Google Code.
I've added it here:
http://codereview.appspot.com/repos
as a repository. You should be able to create an issue for review there?
So I ran into the data type problem trying to replace
plistlib.readPlistFromString using NSString's propertyList method that
you mentioned earlier.
It's an annoying problem.
Google Code appears to have that
(http://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control)
so it's the path of least resistance.
However, I'm leaning in the direction of either bailing entirely on
Google Code and sticking with Git & GitHub or switching to BitBucket,
which has an issue tracker, forking and other niceties:
http://bitbucket.org/acdha/pymacadmin/overview/
The nice part is that since we're using a DVCS we can easily do things
like keep BitBucket and Google Code in sync. As far as which one, I'm
fairly agnostic - I use git the most but Mercurial seems to get a
better reception from newcomers. Should we just do a straw-poll before
too much work goes on? I'm entirely comfortable saying we'll just
ditch Google Code and move the entire thing to github if that's the
popular choice. If we stick with Mercurial, I'll leave Google Code up
since there's no pain keeping it in sync.
Chris
> The main nod to Mercurial is simply that it lets us use Google Code
> natively while still taking advantage of full DVCS support: people can
> fork on BitBucket if they like but it's not a critical link the way
> GitHub would be if we were using them for everything.
Given the power of inertia, and the rather slow rate of development -
I think just sticking on Google code makes sense.
It has a better-than-I-thought issue tracker, and a modern DVCS backend
I think we should all just be thankful we have a bounty of choice and
aren't stuck with sourceforge CVS anymore ;-)
-Preston
Chris
It occurred to me that, while I have written a non-trivial amount of
python code, aside from snippets in questions I've asked, no one else
has actually looked at my python code, and I've been unconcerned with
coding conventions and the like. I did read through PEP 8, and, while
I have a hard time seeing how to make all lines fit within 80
characters (especially the first line of a docstring for a function),
a coding standard seems like a good thing. (Do we want one?
Something like, "Go with PEP 8, but we encourage change X and Y"?)
I ran pylint on my module, and got an overall rating of .... 2.8 out
of 10!
2. Next, module importing. I know we want to limit external modules
as much as possible, but I'm importing pexpect for use where
subprocess didn't cut it. (I did try accessing directory services
through pyobjc, and, while it is probably possible, I needed to get
work done and provided a wrapper for dsimport and dscl.)
I would also like to use the FoundationPlist module that Greg Neagle
submitted for some additional code I plan to write in this module, and
was wondering if there are any gotchas in importing what is very
likely to be an internal module.
3. Documentation. Before someone can use the module (beyond
mimicking some simple examples), they really need to understand a
thing or two about directory services. I'm willing to write
documentation on it (time permitting). Should I put it on the google
code wiki, in the project in a doc directory, or somewhere else?
4. Lastly, I'd like to re-iterate Greg's question: how do I submit
the code? Is there a mercurial repository running; do I need commit
access, or e-mail code to someone in charge?
Cheers,
Clinton Blackmore
PEP-8 is a good starting point but it definitely has problems with
PyObjC because the Cocoa conventions are so radically different. My
preferred - but not perfectly consistent - approach has been to try
PEP-8 for things which Python programmers use and Cocoa for things
which are dealing with native APIs and assume familiarity with Cocoa
style.
Oh, and since it's been 15+ years since I've needed to work on an
80-char display, I bumped pylint up to 132 characters. For docstrings,
however, it might be reasonable to do something like this:
"""
Short title or summary
paragraphs of text
"""
> 2. Next, module importing. I know we want to limit external modules
> as much as possible, but I'm importing pexpect for use where
> subprocess didn't cut it.
Working code trumps hypothetical code. In this case, you can
transparently clean the code up later as long as your public interface
is stable - it sounds like this would be a great case for someone to
later contribute a native version of the DS interface code and remove
the pyexpect dependency.
> I would also like to use the FoundationPlist module that Greg Neagle
> submitted for some additional code I plan to write in this module, and
> was wondering if there are any gotchas in importing what is very
> likely to be an internal module.
Not to my knowledge - and it's good to reuse code within the project
since that's going to improve quality of the libraries, too.
> 3. Documentation. Before someone can use the module (beyond
> mimicking some simple examples), they really need to understand a
> thing or two about directory services. I'm willing to write
> documentation on it (time permitting). Should I put it on the google
> code wiki, in the project in a doc directory, or somewhere else?
The Google Code wiki is good for complex, multi-page documents. If you
need less you might want to just put a README.rst file in the project
directory but it sounds like you're already talking at least a couple
of web pages so I'd go straight to the wiki.
> 4. Lastly, I'd like to re-iterate Greg's question: how do I submit
> the code? Is there a mercurial repository running; do I need commit
> access, or e-mail code to someone in charge?
There is a Mercurial repository:
http://code.google.com/p/pymacadmin/source/checkout
I'm not sure what the preferred development style is - we've been
pretty open about Google Code permissions, and you can just email me
or Nigel if you want commit access there.
There's also a copy at BitBucket where anyone who wants can simply
click the fork button and start working on their own repo, kicking
changes over as needed:
http://bitbucket.org/acdha/pymacadmin/
As a general rule, I'd say we've been pretty welcoming but if you want
to work on something which you're unsure of it might be easier to work
on your own repo and send a pull request when you're happy with it.
This would probably be the preferred strategy for a major feature
change - e.g. if someone wanted to completely change the way crankd
worked, they might want to track us a bit but have a full repository
for their own branches & contributors before pushing a finished
product back. I don't think we're big enough to need that yet,
however.
Chris
>
> On Sat, Aug 29, 2009 at 12:27 PM, SABRE
> Robotics<sabre.r...@gmail.com> wrote:
>>
>> 1. I've been working on (and using) a directory service's module
>> that
>> I'd like to clean up and submit for inclusion with pymacadmin.
>
> Have you looked at Snow Leopard? :)
>
> We have a nice framework we can get to in python now....
I haven't actually.
Today is the first day of school, and I, being a K-12-school-division
computer tech, anticipate, barring any insanity, that I'll be
administering, almost exclusively, 10.5 Leopard machines for the next
ten months.
That said, would you elaborate on what Snow Leopard offers in this
regard? (And, does it compile for Leopard! (Sigh))
>
Clinton Blackmore
If you are able to find out, I can avoid a naming conflict with my
module (which, right now, is 'directoryservice'). There is no rush,
mind you.
Clinton
If you are able to find out [the name of the new Directory Services framework],
I can avoid a naming conflict with mymodule (which, right now, is 'directoryservice'). There is no rush,mind you.
He is talking about a ObjC framework - not a module, so different
namespace.
However I think Chris' comment is a key one. Focus on a clean and
usable python side API and the implementation can branch on OS Version
and be updated without breaking code that uses your module (thats
where a good test comes in handy - not that I'm the best at following
that advice).
There could well be features available through the framework that are
not through dscl
Are you using an OO or procedural design?
I think this module:
http://mike.verdone.ca/twitter/
Shows how you can have a very simple design for mapping a path based
API (in this case twitter) to a dotted object addressing in python.
I think this could be a cool approach for the path portion of a DS
module
-Preston
That's incredible! Holy cow. Most of it lies within http://github.com/sixohsix/twitter/blob/7985672c869426c961ea96565aa0d8695a63513d/twitter/api.py
which is only 120 lines (if you don't count the docstrings)
I assume that the magic lies within the __getattr__ and __call__
methods -- that this is what allows him to say you can call a function
called
twitter.statuses.friends_timeline(id="billybob")
(or even twitter.statuses.friends_timeline.billybob())
and although it is not defined anywhere, it works. [Well, according
to the docs; I haven't actually tested it.]
Man. Wow. I new that my grasp of python wasn't excellent, but I am
just flabbergasted by this.
Wow. And here I had wondered idly about subclass dict to make
directory access pythonic. I am impressed.
Thanks again, Preston.
Clinton
I've been inspired to make it a lot better. We'll see what actually
happens. I would love feedback; I'm not going to get any better at
this if I don't find out what I've been doing wrong. As they say, the
biggest room is the room for improvement. (That said, I've made very
little effort to clean up the code, and, although it is useable as-is,
it should be regarded as highly unstable.)
Cheers,
Clinton Blackmore
> No, none of this will be available for Leopard.
>
> Snow Leopard gives us two *really* useful frameworks we can get to in
> Python, one for DirectoryServices, the other for launchd
> (ServiceManagement)
>
> I can't remember the DS ones name off the top of my head.
What about CoreWLAN? Has anyone tried anything with that public framework?
--
Jeremy
I have actually, but not from Python as yet. Testing now shows it's
not available for import out of the box.
I was disappointed, I think the problem was that you still couldn't
programmatically work with certificates or something?
> I have actually, but not from Python as yet. Testing now shows it's
> not available for import out of the box.
>
> I was disappointed, I think the problem was that you still couldn't
> programmatically work with certificates or something?
I saw the same thing, but I'm not totally hip with PyObjC so I wasn't clear
I was trying to import the right thing. Does that mean there must be "glue"?
At least networksetup has new options for exporting and importing 802.1X
profiles, optionally with keychain items. See the man page, look for
-export8021xProfiles and -import8021xProfiles.
--
Jeremy
For what it's worth, I vote for anything that uses for Mercurial over Git or
Bzr. My team at work uses Hg, I use Hg personally (and use it with
Bitbucket), and I lack the time/patience/desire to pick up another (D)VCS
right now.
But then again, I haven't contributed anything yet. :)
--
Jeremy