Файл: pyramid.pdf

19.1. PASTEDEPLOY

40level = NOTSET

41formatter = generic

42

43[formatter_generic]

44format = %(asctime)s %(levelname)-5.5s [%(name)s][%(threadName)s] %(message)s

45

46 # End logging configuration

The line in [app:main] above that says use = egg:MyProject is actually shorthand for a longer spelling: use = egg:MyProject#main. The #main part is omitted for brevity, as #main is a default defined by PasteDeploy. egg:MyProject#main is a string which has meaning to PasteDeploy. It points at a setuptools entry point named main defined in the MyProject project.

Take a look at the generated setup.py file for this project.

10’pyramid’,

11’pyramid_debugtoolbar’,

12’waitress’,

13]

14

15setup(name=’MyProject’,

16version=’0.0’,

17description=’MyProject’,

18long_description=README + ’\n\n’ + CHANGES,

19classifiers=[

20"Programming Language :: Python",

21"Framework :: Pylons",

22"Topic :: Internet :: WWW/HTTP",

23"Topic :: Internet :: WWW/HTTP :: WSGI :: Application",

24],

25author=’’,

26author_email=’’,

27url=’’,

28keywords=’web pyramid pylons’,

29packages=find_packages(),

30include_package_data=True,

209

19. PASTEDEPLOY CONFIGURATION FILES

Note that the entry_point line in setup.py points at a string which looks a lot like an .ini file. This string representation of an .ini file has a section named [paste.app_factory]. Within this section, there is a key named main (the entry point name) which has a value myproject:main. The key main is what our egg:MyProject#main value of the use section in our config file is pointing at, although it is actually shortened to egg:MyProject there. The value represents a dotted Python name path, which refers to a callable in our myproject package’s __init__.py module.

The egg: prefix in egg:MyProject indicates that this is an entry point URI specifier, where the “scheme” is “egg”. An “egg” is created when you run setup.py install or setup.py develop within your project.

In English, this entry point can thus be referred to as a “PasteDeploy application factory in the MyProject project which has the entry point named main where the entry point refers to a main function in the mypackage module”. Indeed, if you open up the __init__.py module generated within any scaffold-generated package, you’ll see a main function. This is the function called by PasteDeploy when the pserve command is invoked against our application. It accepts a global configuration object and returns an instance of our application.

19.1.2 [DEFAULTS] Section of a PasteDeploy .ini File

You can add a [DEFAULT] section to your PasteDeploy .ini file. Such a section should consists of global parameters that are shared by all the applications, servers and middleware defined within the configuration file. The values in a [DEFAULT] section will be passed to your application’s main function as global_config (see the reference to the main function in __init__.py).

210

CHAPTER

TWENTY

COMMAND-LINE PYRAMID

Your Pyramid application can be controlled and inspected using a variety of command-line utilities. These utilities are documented in this chapter.

20.1 Displaying Matching Views for a Given URL

For a big application with several views, it can be hard to keep the view configuration details in your head, even if you defined all the views yourself. You can use the pviews command in a terminal window to print a summary of matching routes and views for a given URL in your application. The pviews command accepts two arguments. The first argument to pviews is the path to your application’s .ini file and section name inside the .ini file which points to your application. This should be of the format config_file#section_name. The second argument is the URL to test for matching views. The section_name may be omitted; if it is, it’s considered to be main.

Here is an example for a simple view configuration using traversal:

211

20. COMMAND-LINE PYRAMID

The output always has the requested URL at the top and below that all the views that matched with their view configuration details. In this example only one view matches, so there is just a single View section. For each matching view, the full code path to the associated view callable is shown, along with any permissions and predicates that are part of that view configuration.

A more complex configuration might generate something like this:

1 $ ../bin/pviews development.ini#shootout /about

2

3 URL = /about

4

5 context: <shootout.models.RootFactory object at 0xa56668c>

6view name: about

7

8Route:

9------

10route name: about

11route pattern: /about

12route path: /about

13subpath:

14route predicates (request method = GET)

15

16View:

17-----

18shootout.views.about_view

19required permission = view

20view predicates (request_param testing, header X/header)

21

22Route:

23------

24route name: about_post

25route pattern: /about

26route path: /about

27subpath:

28route predicates (request method = POST)

29

30View:

31-----

32shootout.views.about_view_post

33required permission = view

34view predicates (request_param test)

35

36View:

37-----

38shootout.views.about_view_post2

39required permission = view

212

20.2. THE INTERACTIVE SHELL

40 view predicates (request_param test2)

In this case, we are dealing with a URL dispatch application. This specific URL has two matching routes. The matching route information is displayed first, followed by any views that are associated with that route. As you can see from the second matching route output, a route can be associated with more than one view.

For a URL that doesn’t match any views, pviews will simply print out a Not found message.

20.2 The Interactive Shell

Once you’ve installed your program for development using setup.py develop, you can use an interactive Python shell to execute expressions in a Python environment exactly like the one that will be used when your application runs “for real”. To do so, use the pshell command line utility.

The argument to pshell follows the format config_file#section_name where config_file is the path to your application’s .ini file and section_name is the app section name inside the

.ini file which points to your application. For example, if your application .ini file might have a [app:main] section that looks like so:

If so, you can use the following command to invoke a debug shell using the name main as a section name:

213

20. COMMAND-LINE PYRAMID

>>> root

<myproject.resources.MyResource object at 0x445270>

>>>registry <Registry myproject>

>>>registry.settings[’pyramid.debug_notfound’] False

>>>from myproject.views import my_view

>>>from pyramid.request import Request

>>>r = Request.blank(’/’)

>>>my_view(r)

{’project’: ’myproject’}

The WSGI application that is loaded will be available in the shell as the app global. Also, if the application that is loaded is the Pyramid app with no surrounding middleware, the root object returned by the default root factory, registry, and request will be available.

You can also simply rely on the main default section name by omitting any hash after the filename:

chrism@thinko env26]$ bin/pshell starter/development.ini

Press Ctrl-D to exit the interactive shell (or Ctrl-Z on Windows).

20.2.1 Extending the Shell

It is convenient when using the interactive shell often to have some variables significant to your application already loaded as globals when you start the pshell. To facilitate this, pshell will look for a special [pshell] section in your INI file and expose the subsequent key/value pairs to the shell. Each key is a variable name that will be global within the pshell session; each value is a dotted Python name. If specified, the special key setup should be a dotted Python name pointing to a callable that accepts the dictionary of globals that will be loaded into the shell. This allows for some custom initializing code to be executed each time the pshell is run. The setup callable can also be specified from the commandline using the --setup option which will override the key in the INI file.

For example, you want to expose your model to the shell, along with the database session so that you can mutate the model on an actual database. Here, we’ll assume your model is stored in the myapp.models package.

214