packaging of Python client library

[Chad Whitacre]

Greetings,

Thanks for the new Python client library! I've had a project on
the back burner for a few months and was surprised to find this
library waiting for me now that I'm getting around to it. A few
recommendations as I install it here:

1. The normal way to package and install Python libraries is
with distutils (although setuptools is gaining steam). This
means writing a setup.py script:

http://docs.python.org/dist/dist.html

2. Python packages of similar scope usually use a nested
structure, i.e., this:

gdata/__init__.py
gdata/gbase/__init__.py
gdata/gbase/service.py

Instead of this:

gdata.py
gbase.py
gbase_service.py

3. Tests are usually kept in a separate subpackage rather than
interspersed with actual modules.

4. In the absence of documentation, you could at least
generate some basic API docs with Epydoc:

http://epydoc.sourceforge.net/

I've taken the liberty of posting such docs here:

http://tech2.whit537.org/2007/gdata-python/1.0/

Not sure if these were intentional departures or not, but thought
I'd mention them as I would have found the library more
immediately comfortable without them.

Thanks again! Looking forward to using the library.

chad

[j...@google.com]

Hi chad,

Thank you for the feedback! I've added these suggestions to the list
of issues in the project here http://code.google.com/p/gdata-python-client/issues/list
and I'd also like to invite you to participate in the discussion which
has been surrounding new ideas for the library in the contributor's
group here: http://groups.google.com/group/gdata-python-client-library-contributors

On Mar 30, 8:31 pm, Chad Whitacre <c...@zetaweb.com> wrote:
> Greetings,
>
> Thanks for the new Python client library! I've had a project on
> the back burner for a few months and was surprised to find this
> library waiting for me now that I'm getting around to it. A few
> recommendations as I install it here:
>
> 1. The normal way to package and install Python libraries is
> with distutils (although setuptools is gaining steam). This
> means writing a setup.py script:
>
> http://docs.python.org/dist/dist.html

At the moment I'm leaning towards setuptools. I didn't include it in
the initial release because it seemed like the project was simple
enough but I think that the need for a configuration file will grow
quickly.

>
> 2. Python packages of similar scope usually use a nested
> structure, i.e., this:
>
> gdata/__init__.py
> gdata/gbase/__init__.py
> gdata/gbase/service.py
>
> Instead of this:
>
> gdata.py
> gbase.py
> gbase_service.py

I agree, and with more modules on the way the need is even greater. I
was thinking of a directory structure like this:
http://code.google.com/p/gdata-python-client/issues/detail?id=11 ,
does this seem more usable?

>
> 3. Tests are usually kept in a separate subpackage rather than
> interspersed with actual modules.

Agreed, I plan to create a testing folder and also a script to run all
of the tests.

>
> 4. In the absence of documentation, you could at least
> generate some basic API docs with Epydoc:
>
> http://epydoc.sourceforge.net/
>
> I've taken the liberty of posting such docs here:
>
> http://tech2.whit537.org/2007/gdata-python/1.0/

We decided to not use epydoc syntax but I agree that online
documentation would be very helpful. I'd like to discuss this further
with you and with the other developers on the project to figure out
how be to provide docs and thank you for posting the docs you
generated.

>
> Not sure if these were intentional departures or not, but thought
> I'd mention them as I would have found the library more
> immediately comfortable without them.

Some were intentional, and others were points I neglected and in
either case I'm sorry to trouble you. Thank you again for helping to
make this library better! Your feedback has been invaluable and it
confirms many of my own feelings.

Happy coding,

Jeff