Capirca Packaging

[j...@thejof.com]

I'm looking to package up Capirca for internal use, and am wondering a few things about the code/repository organization.

Firstly, it seems that much of the platform code is in the "lib" module. Is there a reason for such a generic name? It would seem to me like it'd make a lot more sense to package everything up under a namespace like "capirca".

Is there a reason to stick with "lib"? I'd very much like to move things to exist like "capirca.cisco", "capirca.aclgen", etc.

This would be a non-trivial re-factoring, so any external code that uses these libraries directly would have to have an interface change.

Second question is one about CLI utilities like aclgen, definate, and aclcheck_cmdline.

Any reason not to list these as "scripts" to distutils so that they show up as executables?

Cheers,

jof

[Peter Moody]

On Tue, May 7, 2013 at 4:07 PM, <j...@thejof.com> wrote:

> Firstly, it seems that much of the platform code is in the "lib" module. Is
> there a reason for such a generic name? It would seem to me like it'd make a
> lot more sense to package everything up under a namespace like "capirca".
> Is there a reason to stick with "lib"? I'd very much like to move things to
> exist like "capirca.cisco", "capirca.aclgen", etc.

Why?

--
[ Peter Moody | Security Engineer | Google ]

[Jonathan Lassoff]

On Tue, May 7, 2013 at 4:09 PM, Peter Moody <pmo...@google.com> wrote:
> On Tue, May 7, 2013 at 4:07 PM, <j...@thejof.com> wrote:
>
>> Firstly, it seems that much of the platform code is in the "lib" module. Is
>> there a reason for such a generic name? It would seem to me like it'd make a
>> lot more sense to package everything up under a namespace like "capirca".
>> Is there a reason to stick with "lib"? I'd very much like to move things to
>> exist like "capirca.cisco", "capirca.aclgen", etc.
>
> Why?

Internal packaging policy that states that modules should be
namespaced under packages in a way that makes sense for the library or
project.

"lib" is pretty confusing to someone that doesn't know about capirca.

Most other Python libraries and projects organize their code in this
fashion, so I was wondering if it'd be possible to make similar
organizations for Capirca.

I can't package it in its current state, and I _really_ don't want to
fork the SVN repo internally, since it would lead to re-integration
headaches down the road.


Is there any reason not to re-organize capirca in this fashion?
Maybe a transitional state could be created where the packages are
installed under a "capira" dot-path, but are symlinked such that
they're still accessible by the old names.

Cheers,
jof

[Peter Moody]

On Tue, May 7, 2013 at 4:14 PM, Jonathan Lassoff <j...@thejof.com> wrote:

> Internal packaging policy that states that modules should be
> namespaced under packages in a way that makes sense for the library or
> project.

is this debian-internal or something or some company-internal?

> Is there any reason not to re-organize capirca in this fashion?

Tony's the workhorse here, but generally lib/ is how things are laid
out here, so changing the layout like this would mean us having a
forked version (which to some degree we already do) or having to spend
time having to change how things are laid out to comply with your
packaging policy.

Cheers,
peter

[Jonathan Lassoff]

On Tue, May 7, 2013 at 4:24 PM, Peter Moody <pmo...@google.com> wrote:
> is this debian-internal or something or some company-internal?

[some company]-internal, though Debian haas similar requirements as well.

> Tony's the workhorse here, but generally lib/ is how things are laid
> out here, so changing the layout like this would mean us having a
> forked version (which to some degree we already do) or having to spend
> time having to change how things are laid out to comply with your
> packaging policy.

Interesting. I can certainly see how it makes sense to have a
top-level lib/ in your project directory, but it's when it gets
installed as "lib" that my conflict is happening.
Is the Google policy to keep sources in your VCS under lib/, or is it
to install Python packages/modules under "lib"?

This is not a request to do work to fit my company's packaging policy.
I'm happy to do the work to rename things in the repository, and line
up all the names and setup.py nicely.

Cheers,
jof

[Tony Watson]

I guess I'm not sure what the concern is here. 

There is package capirca, which contains a lib directory with libraries.  This is pretty standard and common.  Placing the libraries into a capirca subdirectory under a capirca parent directory would just be confusing IMHO.

--
You received this message because you are subscribed to the Google Groups "capirca-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capirca-dev...@googlegroups.com.
To post to this group, send email to capir...@googlegroups.com.
Visit this group at http://groups.google.com/group/capirca-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Jonathan Lassoff]

Hello Tony!

So, my concern is no so much about the "lib" under the project root.
That seems totally reasonable to me.
My concern is more around this statement:
https://code.google.com/p/capirca/source/browse/trunk/setup.py#33

When the python packages actually get installed, they're installed
under "lib". So, at import-time one would have to call "import
lib.cisco", "import lib.aclcheck", etc. I'm looking to write external
tools that utilize Capirca functions, combining it with other things
like Fabric.

Having everything namespaced under "lib" in unconventional and
confusing. It would make much more sense to me if we could import like
"import capirca.cisco" and "import capirca.aclcheck".

What about just adding a statement to setup.py like:

package_dir = { 'capirca': 'lib' }

And switching "aclgen" and "definiate" to be scripts:

scripts = [ 'definate', 'aclgen' ]

Cheers,
jof