mycompany.myapp instead of myapp as base package ?

[Guillaume]

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 ?

Regards,
Guillaume

[Gael Pasgrimaud]

Hi,

I think that the only things needed is to have a valid entry point for
each apps. in setup.py:

[paste.app_factory]
app1 = mycompany.app1.config.middleware:make_app
app2 = mycompany.app2.config.middleware:make_app

Then edit your .ini file to something like:

[app:main]
use = Paste#urlmap
/app1 = app1
/app2 = app2

[app:app1]
use = MyCompany#app1
# conf for app1

[app:app2]
use = MyCompany#app2
# conf for app2

--
Gael

[Mike Orr]

On Fri, Dec 12, 2008 at 7:58 AM, Gael Pasgrimaud <ga...@gawel.org> wrote:
>
> Hi,
>
> I think that the only things needed is to have a valid entry point for
> each apps. in setup.py:
>
> [paste.app_factory]
> app1 = mycompany.app1.config.middleware:make_app
> app2 = mycompany.app2.config.middleware:make_app
>
> Then edit your .ini file to something like:
>
> [app:main]
> use = Paste#urlmap
> /app1 = app1
> /app2 = app2
>
> [app:app1]
> use = MyCompany#app1
> # conf for app1
>
> [app:app2]
> use = MyCompany#app2
> # conf for app2

The default model is an empty stub that the rest of Pylons does not
depend on, so you can put it anywhere. This is not true for templates
or controllers. If you want to share those, you'll have to adjust the
paths in environment.py.

--
Mike Orr <slugg...@gmail.com>

[aaron]

I have a setup like this, which seems to work ok, except for one major
issue: "paster shell" doesn't work.

So, our entry points in setup.py:
entry_points={
"paste.app_factory": ["main =
mycompany.myapp.config.middleware:make_app"],
"paste.app_install": ["main = pylons.util:PylonsInstaller"]
}

When I run "paster shell", I get the error:
ImportError: Could not import base module. Are you sure this is a
Pylons app?

I can fix this by manually editing "top_level.txt" and adding
"mycompany.myapp"... but this is a pain to do this after each run of
setup.py. Is there a fix for this? or is it a bug?

-a

On Dec 12, 7:58 am, "Gael Pasgrimaud" <g...@gawel.org> wrote:
> Hi,
>
> I think that the only things needed is to have a valid entry point for
> each apps. in setup.py:
>
>     [paste.app_factory]
>     app1 = mycompany.app1.config.middleware:make_app
>     app2 = mycompany.app2.config.middleware:make_app
>
> Then edit your .ini file to something like:
>
>    [app:main]
>    use = Paste#urlmap
>    /app1 = app1
>    /app2 = app2
>
>    [app:app1]
>    use = MyCompany#app1
>    # conf for app1
>
>    [app:app2]
>    use = MyCompany#app2
>    # conf for app2
>
> --
> Gael
>

[Mike Orr]

On Fri, Dec 12, 2008 at 3:22 PM, aaron <taco...@gmail.com> wrote:
>
> I have a setup like this, which seems to work ok, except for one major
> issue: "paster shell" doesn't work.
>
> So, our entry points in setup.py:
> entry_points={
> "paste.app_factory": ["main =
> mycompany.myapp.config.middleware:make_app"],
> "paste.app_install": ["main = pylons.util:PylonsInstaller"]
> }
>
> When I run "paster shell", I get the error:
> ImportError: Could not import base module. Are you sure this is a
> Pylons app?
>
> I can fix this by manually editing "top_level.txt" and adding
> "mycompany.myapp"... but this is a pain to do this after each run of
> setup.py. Is there a fix for this? or is it a bug?

The whole way Setuptools works is a bug, and the fact that package
management isn't built into Python is another bug. Entry points have
a way of sometimes working and sometimes not, and when
pkg_resources.require() fails it tells you what it was looking for but
not who was asking for it, so it can be hard to track down where the
dependency is. So one should just be happy it works at all.

In this case it says "Pylons" in the error message so there's a little
more to go on.

$ grep -r 'is a Pylons app' ~/hg/Pylons/pylons | egrep -v 'Binary|\.pyc'
/home/mso/hg/Pylons/pylons/commands.py:
"this is a Pylons app?")

Here's the source:

===
# Import all objects from the base module
base_module = pkg_name + '.lib.base'
found_base = can_import(base_module)
if not found_base:
# Minimal template
base_module = pkg_name + '.controllers'
found_base = can_import(base_module)

if not found_base:
raise ImportError("Could not import base module. Are you sure "
"this is a Pylons app?")

===

So you may not be able to do your applications-under-a-namespace idea
without hacking Pylons.

If your goal is to share a model, it would make more sense to put the
model in a separate package and make both applications depend on it.

--
Mike Orr <slugg...@gmail.com>

[Jorge Vargas]

I just wanted to say I have this exact same problem. With a project we
decided to namespace, our current solution is to not use paster shell,
due to the setuptools problems Mike outlined

[aaron]

> I just wanted to say I have this exact same problem. With a project we
> decided to namespace, our current solution is to not use paster shell,
> due to the setuptools problems Mike outlined

I've added a ticket:
http://pylonshq.com/project/pylonshq/ticket/549

-a

[Wyatt Baldwin]

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.

[Jorge Vargas]

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

[Wyatt Baldwin]

On Dec 15, 4:27 pm, "Jorge Vargas" <jorge.var...@gmail.com> wrote:
> On Mon, Dec 15, 2008 at 6:07 PM, Wyatt Baldwin
>

Does it "break" `paster shell`? When I run `paster shell` with this
setup, it loads everything correctly, as far as I can tell. If you
import your model into your Pylons app's lib/base.py, `paster shell`
will load it. Otherwise, you can just do a `from mycompany.core import
model` in paster shell. I don't see what's broken about that--it seems
like `paster shell` is just doing some imports for you as a
convenience (amongst other things).

Also, I don't see why it matters where your INI file is located. In
fact, when you create a new Pylons project, the INI files aren't
technically in a package--they're in the project directory.

Are there other aspects of `paster shell` that are broken when using
namespaced packages?

[Jorge Vargas]

I'll take another look at this on the project I'm referring to I
wasn't the one that namespaced it nor have I look deeply into the
project. I took it for granted I'll take a look to see if our setup is
different than yours and report back.

[Andrey Plotnikov]

I got stuck on the same problem. I run this script (attached) from
ipython to get identical testing environment.
Script code is the same pylons shell code (0.9.6) with small fixes.
And for my taste it is more convenient (for me to) to "embed" pylons
environment into ipython than embed ipython to pylons.

--
Andrey Plotnikov