How to make a submission?

3 views
Skip to first unread message

Greg Neagle

unread,
Aug 20, 2009, 11:15:03 AM8/20/09
to pymac...@googlegroups.com
So I wrote a FoundationPlist.py library to (mostly) replace plistlib
on the Mac. I'd like to be able to submit it for comment and review,
and then have it added to the libraries available through PyMacAdmin.

Is there a way to do this?

-Greg

Nigel Kersten

unread,
Aug 20, 2009, 12:12:35 PM8/20/09
to pymac...@googlegroups.com

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.

Greg Neagle

unread,
Aug 20, 2009, 12:30:39 PM8/20/09
to pymac...@googlegroups.com
I see the repo added at the bottom of that page, but have no idea at
all what to do with it.

I suspect Google Groups will strip this, but if not, here's the
library as an attachment:

FoundationPlist.py

Preston Holmes

unread,
Aug 20, 2009, 1:55:35 PM8/20/09
to pymac...@googlegroups.com
What do people think about moving the repo to a host that has an
integrated issue tracker?

Makes it very easy to associate commits with issues.

I've been happy with bitbucket - I know Github has more buzz.

I see that Chris already keeps his copy on Github - not clear if that
is the true master of the project or a fork from Google Code

For example with bitbucket you can just mention:

fixes #235

in a commit and it will mark the corresponding issue as closed

Then its just a matter of any committer committing to truck and others
testing and submitting issues.

I think this is basically a decision for Chris and Nigel - they may
prefer to keep code here, (mercurial yay) and issue tracker on the
appengine app - or a Trac instance.

-Preston
> <FoundationPlist.py>
>> --~--~---------~--~----~------------~-------~--~----~
>> You received this message because you are subscribed to the Google
>> Groups "PyMacAdmin" group.
>> To post to this group, send email to pymac...@googlegroups.com
>> To unsubscribe from this group, send email to pymacadmin+...@googlegroups.com
>> For more options, visit this group at http://groups.google.com/group/pymacadmin?hl=en
>> -~----------~----~----~----~------~----~------~--~---
>>
>

Nigel Kersten

unread,
Aug 20, 2009, 1:59:01 PM8/20/09
to pymac...@googlegroups.com
I think we just started using Google Code because it was easy.

I'm actually not familiar with mercurial at all, and am not really
looking forward to learning yet another VCS as day to day I only
really work in perforce and git these days.

I don't have a strong preference either way really.

SABRE Robotics

unread,
Aug 20, 2009, 2:05:42 PM8/20/09
to pymac...@googlegroups.com
Attaching the file seemed to work fine.

I like your module. I think that's a great way to wrap functionality
-- it is a lot clearer and cleaner to write code that uses this than
to access the Cocoa stuff directly (and heck, that makes it accessible
to those who would be entirely scared off by PyObjC).

Pertaining to other recent discussions, I am all for the idea of
having an easily imported family of modules under the PyMacAdmin banner.

Clinton
> <FoundationPlist.py>
>
> On Aug 20, 2009, at 9:12 AM, Nigel Kersten wrote:
>
>>

SABRE Robotics

unread,
Aug 20, 2009, 2:33:28 PM8/20/09
to pymac...@googlegroups.com
I use bzr ( http://bazaar-vcs.org/ ) for my projects on my own
machine, and if (when?) I ever create my own open-source project, I'll
seriously considering using launchpad ( https://launchpad.net/ ). bzr
is a distributed version control system that is designed to be easy to
use (and it is), and it integrates with launchpad.

How is that for topical: I just clicked on the "take the tour" link
for launchpad ( https://launchpad.net/+tour/index ), and the first two
things it mentions are bug tracking and code hosting and review.

One more comment on the FoundationPlist -- I'd never thought of
putting a plist in a string, but if I have to populate MCX settings by
script in my open directories (which looks quite plausible), I'll be
sure to use it. Great idea.

Cheers,
Clinton

Chris Adams

unread,
Aug 20, 2009, 9:46:15 PM8/20/09
to pymac...@googlegroups.com
On Thu, Aug 20, 2009 at 1:55 PM, Preston Holmes<sanroq...@gmail.com> wrote:
> What do people think about moving the repo to a host that has an
> integrated issue tracker?

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

Nigel Kersten

unread,
Aug 21, 2009, 10:18:04 AM8/21/09
to pymac...@googlegroups.com
How is the performance of bitbucket?

I use github just about every single day, and there have been periods
where the performance is utterly atrocious, so much so that it
actively annoys you.

That's about the main pro factor for Google Code imho. Performance
problems have been very rare.

Chris Adams

unread,
Aug 21, 2009, 11:33:03 AM8/21/09
to pymac...@googlegroups.com
That's *exactly* why I've stayed with Google Code - I have the same
daily experience with GitHub acting like the Twitter of project
hosting. BitBucket has been better (which might simply be less
traffic) but Google definitely has considerably more infrastructure
experience.

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.

Chris

Preston Holmes

unread,
Aug 21, 2009, 4:20:32 PM8/21/09
to pymac...@googlegroups.com

On Aug 21, 2009, at 8:33 AM, Chris Adams wrote:

> 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 Adams

unread,
Aug 21, 2009, 4:44:50 PM8/21/09
to pymac...@googlegroups.com
That's my feeling as well, particularly since Git, Mercurial, bzr,
etc. all seem to be roughly feature equivalent in normal usage. The
syntax is different but they're all so much better at working
independently and merging that it's not worth worrying about what's
left.

Chris

SABRE Robotics

unread,
Aug 29, 2009, 3:27:17 PM8/29/09
to pymac...@googlegroups.com
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.

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

Chris Adams

unread,
Aug 29, 2009, 4:20:21 PM8/29/09
to pymac...@googlegroups.com
On Sat, Aug 29, 2009 at 3:27 PM, SABRE Robotics<sabre.r...@gmail.com> wrote:
> Something like, "Go with PEP 8, but we encourage change X and Y"?)

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

Nigel Kersten

unread,
Aug 30, 2009, 1:47:55 AM8/30/09
to pymac...@googlegroups.com
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....

SABRE Robotics

unread,
Aug 31, 2009, 12:19:48 PM8/31/09
to pymac...@googlegroups.com

On 29-Aug-09, at 11:47 PM, Nigel Kersten wrote:

>
> 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

SABRE Robotics

unread,
Aug 31, 2009, 12:21:22 PM8/31/09
to pymac...@googlegroups.com
Thanks, Chris, for answering all of my questions.

Regarding the wiki, do I need to e-mail you or Nigel for write access,
and am I able to upload images for use in the pages?

I've started looking into Mercurial.

Cheers,
Clinton

Nigel Kersten

unread,
Aug 31, 2009, 12:31:48 PM8/31/09
to pymac...@googlegroups.com
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.



>>
>
> Clinton Blackmore
>
>
> >
>

SABRE Robotics

unread,
Aug 31, 2009, 1:06:46 PM8/31/09
to pymac...@googlegroups.com
> 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.

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

Preston Holmes

unread,
Aug 31, 2009, 1:34:16 PM8/31/09
to pymac...@googlegroups.com
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


>
> Clinton
>
> >

SABRE Robotics

unread,
Aug 31, 2009, 3:32:44 PM8/31/09
to pymac...@googlegroups.com
If you are able to find out [the name of the new Directory Services framework],
I can avoid a naming conflict with my
module (which, right now, is 'directoryservice').  There is no rush,
mind you.

He is talking about a ObjC framework - not a module, so different  
namespace.


If it is a public framework, you'll still get at it by #import FrameworkName, right?  In which case, a module with the same name would conflict.

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).


That is a good idea.  It concur that using a testing framework would indeed be worthwhile.  Is there one I should prefer?  Also, my current module exists entirely in one file; aside from sheer size, at what point would I want to move to a whole directory?


There could well be features available through the framework that are  
not through dscl

Are you using an OO or procedural design?


I'm using a very procedural design.  I keep adding to it as work continues, but right now usage looks something like this:  (untested)

from directoryservice import DS

directory = DS('hostname', '/LDAPv3/127.0.0.1', 'diradmin', '******')

user_dict = {
"RecordName" : "clinton",
"RealName" : "Clinton Blackmore",
"UniqueID" : 2001,
"UserShell" : "/bin/bash",
"Password" : "wouldn't you like to know?",
"AuthMethod" : "dsAuthMethodStandard:dsAuthClearText",
"Keywords" : [ "Computer Technician", "Programmer" ],
"PrimaryGroupID" : 1025,
"HomeDirectory" : "<home_dir><url>afp://hostname/Users</url><path>clinton_blackmore</path></home_dir>",
"NFSHomeDirectory" = "/Network/Servers/hostname/Volumes/ServerHD/Users/clinton_blackmore"
}

directory.queue_record("Users", user_dict)

# Do the same for more users

(failed_list, succeeded_list) = directory.commit("O") # Overwrite

print "Successfully created %s of %s users" % (len(succeeded_list), len(succeeded_list) + len(failed_list))
if failed:
  print "The following users failed to create: " + ",".join(failed_list)


I recently added a function for changing passwords, and at the moment am making it so records can be deleted.  I have a plan in mind for reading and searching records.  It looks like a number of the functions I am adding will be more interactive than the batch processing functions that already exist.

Part of me wants to say, "That's it?"  Even as it is, though, it has been incredibly useful for my purposes.


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


I will have to take a look at that.  Thank you.

-Preston


Cheers,
Clinton Blackmore

SABRE Robotics

unread,
Aug 31, 2009, 10:23:20 PM8/31/09
to pymac...@googlegroups.com
>
> 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

SABRE Robotics

unread,
Aug 31, 2009, 10:45:59 PM8/31/09
to pymac...@googlegroups.com
Okay, I've uploaded my current code. It is at http://bitbucket.org/clinton_blackmore/pymacadmin/src/tip/lib/PyMacAdmin/directoryservice.py

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

Jeremy Reichman

unread,
Sep 1, 2009, 9:13:46 AM9/1/09
to pymac...@googlegroups.com
On 8/31/2009 12:31 PM, "Nigel Kersten" <ni...@explanatorygap.net> wrote:

> 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


Nigel Kersten

unread,
Sep 1, 2009, 10:29:16 AM9/1/09
to pymac...@googlegroups.com

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?

Jeremy Reichman

unread,
Sep 1, 2009, 11:39:16 AM9/1/09
to pymac...@googlegroups.com
On 9/1/2009 10:29 AM, "Nigel Kersten" <ni...@explanatorygap.net> wrote:

> 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


Jeremy Reichman

unread,
Sep 1, 2009, 11:45:24 AM9/1/09
to pymac...@googlegroups.com

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


Reply all
Reply to author
Forward
0 new messages