On Mon, Dec 15, 2008 at 6:07 PM, Wyatt Baldwin <[email protected]> wrote: > > On Dec 12, 7:29 am, Guillaume <[email protected]> wrote: >> Hi, >> >> I'm currently developing a set of applications, and I have one >> problem. They should all reside in the same package. The package >> structure should look like something like this: >> mycompany/ >> +- models >> | +-base.py >> | +-metadata.py >> | +-app1.py >> | \-app2.py >> +- app1/ >> | +- controllers/... >> | +- helpers.py >> | +- routing.py >> | \- wsgiapp.py >> +- app2/ >> | +- controllers/... >> | +- helpers.py >> | +- routing.py >> | \- wsgiapp.py >> \- ... >> >> Is something like this achievable with pylons ? Or am I restricted to >> have one b >> ase package per application ? > > Here's the setup/layout I'm using to keep my "Core" separate from my > apps, where the Core contains the model, services, utilities, and > anything else that's reusable and/or not specific to a particular > application. Note that I use `pkg_resources`, so the `easy_install`/ > `setuptools` haters may not like this. > > Core/ > ----mycompany/ > --------core/ > ------------model/ > ----------------__init__.py > ----------------<...entity definitions...> > ------------services/ > ----------------__init__.py > ----------------<...service modules...> > ------------__init__.py > --------__init__.py > ----setup.py > > SomeApp/ > ----ini/ > --------development.ini > ----mycompany/ > --------someapp/ > ------------__init__.py > ------------<...other packages and files that import mycompany.core-- > e.g., a Pylons app...> > --------__init__.py > ----setup.py > > At the top level, Core and SomeApp are "project" directories. They > contain project metadata, like the setup file, maybe docs, or utility > scripts that don't need to be installed with the package. > > mycompany/__init__.py, in both projects, contains a single line: > > __import__('pkg_resources').declare_namespace(__name__) > > When these projects are `easy_install`ed, they end up in separate > directories, but there's some "magic" that makes both of them > available from the same namespace, `mycompany`. > > Of course, the OP's directory layout accomplishes (more or less) the > same thing as far as installation is concerned. What I like about this > structure is the complete separation of the Core and the various > projects that depend on it. In the uber-project I'm working on, I have > a (RESTful) Web Service with no GUI built from a stripped down Pylons > app and a separate user facing Web App built on a more "complete" > Pylons app. Both depend on the Core. > > This structure is very useful in helping to keep things straight and > enforces a separation of concerns. I'm using the Web Service app as a > sort of app server--a remote interface to the Core model and services. > The Web App focuses on the user experience, and whenever I start > building some core functionality there, I refactor it into the Core > package and expose it through the WS. > > I haven't been using `paster shell` with this project, but I just ran > it in my SomeApp directory and it seems to work as expected. > This is what's call a namespaced package, and yes I totally agree it's very handy all BIG projects out there use it there is even a tool to create it,
BUT it breaks paster shell as it can't find the model due to the fact that development.ini isn't in the same package, I know the problem we just haven't had time to fix it as this is nice to have but not a priority. Here is a nice writeup on how to use the tool + another good explanation on why this is a good thing, http://www.percious.com/blog/archives/13 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
