What should go in main vs includeme functions in __init__.py?

[pyramidX]

I'm unsure of what I should be putting in the "def main(global_config, **settings):" function and what should go in "def includeme(config):" function in __init__.py for my top-level application package.

Right now they look like this for me, but I patched it together over time and am not sure what is the proper way to be dividing it up.

I see the "config.include('myapp')" is calling includeme, but couldn't I replace that line with the 4 lines from includeme and get rid of includeme? What is the best practice behind using includeme?

def main(global_config, **settings):
    engine = engine_from_config(settings, 'sqlalchemy.')
    DBSession.configure(bind=engine)
    Base.metadata.bind = engine
    config = Configurator(settings=settings)
    config.set_root_factory(RootFactory)
    config.set_session_factory(SignedCookieSessionFactory('...'))
    config.include('myapp')
    config.include('pyramid_mako')
    config.include('pyramid_chameleon')
    config.add_static_view('deform_static', 'deform:static')
    config.add_static_view('static', 'static', cache_max_age=3600)
    config.add_route('home', '/')
    # Add all other routes here...
    config.scan()
    return config.make_wsgi_app()

def includeme(config):
    authz_policy = ACLAuthorizationPolicy()
    config.set_authorization_policy(authz_policy)
    authn_policy = AuthTktAuthenticationPolicy('...', hashalg='sha512')
    config.set_authentication_policy(authn_policy)

I've seen includeme used in some examples of writing pyramid tests, but I'm still not sure. If the idea is to allow tests to have a lot of the context of the regular app, then shouldn't I instead move most of the lines from main to includeme and allow tests to call "config.include('myapp')"? In this case main would just basically return config.make_wsgi_app() after calling includeme?

[Michael Merickel]

On Tue, Dec 16, 2014 at 5:48 AM, pyramidX <veeruk...@hotmail.com> wrote:
> I've seen includeme used in some examples of writing pyramid tests, but I'm
> still not sure. If the idea is to allow tests to have a lot of the context
> of the regular app, then shouldn't I instead move most of the lines from
> main to includeme and allow tests to call "config.include('myapp')"? In this
> case main would just basically return config.make_wsgi_app() after calling
> includeme?

Yep, this is the approach that I take in my apps. The majority of your
app's configuration should go into includeme functions as this is a probably
the best point of modularity within your pyramid structure. You
can include certain features and not include others in tests based on
things like this.

[Randall Leeds]

I've tried to make the distinction between what is my package as a component and what is my package as an application.

So most of my stuff is in includeme, but my root factory config, a status check route, and a favicon route are in main.

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[pyramidX]

What is the difference between component vs application in the way you define it just wondering?

On Tuesday, December 16, 2014 6:09:51 PM UTC+1, Randall Leeds wrote:

I've tried to make the distinction between what is my package as a component and what is my package as an application.

So most of my stuff is in includeme, but my root factory config, a status check route, and a favicon route are in main.

On Tue, Dec 16, 2014, 07:51 Michael Merickel <mmer...@gmail.com> wrote:

On Tue, Dec 16, 2014 at 5:48 AM, pyramidX <veeruk...@hotmail.com> wrote:
> I've seen includeme used in some examples of writing pyramid tests, but I'm
> still not sure. If the idea is to allow tests to have a lot of the context
> of the regular app, then shouldn't I instead move most of the lines from
> main to includeme and allow tests to call "config.include('myapp')"? In this
> case main would just basically return config.make_wsgi_app() after calling
> includeme?

Yep, this is the approach that I take in my apps. The majority of your
app's configuration should go into includeme functions as this is a probably
the best point of modularity within your pyramid structure. You
can include certain features and not include others in tests based on
things like this.

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.

[Chris McDonough]

On 12/16/2014 04:39 PM, pyramidX wrote:
> What is the difference between component vs application in the way you
> define it just wondering?

This might provide a concrete example:

<https://github.com/Pylons/substanced/blob/master/substanced/__init__.py#L4?

config.include('.evolution') for example includes something that
initializes the "evolution" machinery, which makes it possible to define
organized steps to upgrade the database from one state to another. It's
a "component" inasmuch as it's not really required for the rest of the
stuff to work. Most of the includes of stuff in that package are the
same. A person could choose to not use the "main" includeme and create
their own includeme which omitted some components as necessary.

> it, send an email to pylons-discus...@__googlegroups.com
> <javascript:>.

> To post to this group, send email to

> pylons-...@googlegroups.__com <javascript:>.
> Visit this group at
> http://groups.google.com/__group/pylons-discuss
> <http://groups.google.com/group/pylons-discuss>.
> For more options, visit https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pylons-discus...@googlegroups.com

> <mailto:pylons-discus...@googlegroups.com>.

> To post to this group, send email to pylons-...@googlegroups.com

> <mailto:pylons-...@googlegroups.com>.

[Randall Leeds]

On Tue, Dec 16, 2014 at 1:39 PM, pyramidX <veeruk...@hotmail.com> wrote:

What is the difference between component vs application in the way you define it just wondering?

In my case, I was saying that I ask myself these two questions:

"If I were trying to white-label this application, or extend and repurpose it, would I want to include this part?"

"If I am going to invoke this application from the command line, or as a daemon, what things are very deployment specific?"

I try to keep components isolated, and I put very little in the main function. An example might help.

In my main function is code that inspects os.environ and overrides settings. That makes it easy to deploy copies of my application without writing .ini files all the time. But I wouldn't want to surprise someone who just wants to re-use my views or business logic by having that configuration overridden by environment variables. I like to keep those environment variables documented and together in one place, rather than scattered throughout the code base.

So, the question is, "is this part of something isolated and re-usable" or "is this something very top level, specific to this application as I might deploy it".

Hopefully, maybe, that helps a little bit? I think it isn't likely to matter that much. When it does, you'll be able to refactor that quite easily. I think it's good that you have the habit of thinking about and understanding these nuances, but I wouldn't let it distract you from getting things written. :-D