datafolklabs/cement

Application Framework for Python

BJ Dierkes

@derks

This message was deleted

sorry… trying to get an example

import platform

if platform.system().lower() in [‘windows’]:
    EXTENSIONS = ['ext_json']
else:
    EXTENSIONS = [‘ext_daemon’, ‘ext_json']

class MyApp(CementApp):
    class Meta:
        extensions = EXTENSIONS

You need to do a similar check around wherever you call app.daemonize() as well

Craig Schlegelmilch

@cschlegelmilch

OK, that’s sounds straightforward

As for Windows daemon support, in the long run, I think would want it. So consider this a feature request!

BJ Dierkes

@derks

I feel like that might need to be a separate extension

But a solid feature request no doubt

I’ve spent some time in Windows land over the last year to it’s much more do-able now than previously

@cschlegelmilch datafolklabs/cement#457

Craig Schlegelmilch

@cschlegelmilch

So, while I have your attention, I do have another issue related to ext_daemon. If you recall, I support the ability to specify a config file on the command line. We used the post_argument_parsing hook to make that happen. Works great. However, it turns out I can’t specify the pid file location in the user-specified config file because ext_daemon loaded before that hook fires. Am I SOL here or is there a way to re arrange the calls so that I can get the user-specified config file to load before demonize() runs?

BJ Dierkes

@derks

Let me think on that a sec

Where are you calling app.daemonize()? In a hook, or in your controller or somewhere else?

Craig Schlegelmilch

@cschlegelmilch

Its being called early in the execution.

def main():
    with app:
        try:
            if not platform.system().lower() in ['windows']:
                app.daemonize()
            app.args.add_argument('-c', action='store', dest='config', help='Location of config file to parse')
            app.run()
. . .

BJ Dierkes

@derks

Yeah, you need to run it after config parsing happens

You’re calling app.config.parse_file() somewhere else yeah? You need to call app.daemonize() after that

Craig Schlegelmilch

@cschlegelmilch

Indeed. And does the trick. Thanks.

BJ Dierkes

@derks

awesome

Dela Anthonio

@delaanthonio

When I try to get a value using app.config.get('section', 'value') and the value doesn't exist, I get a configparser.NoOptionError, yet I cannot handle this exception since I'm not sure which module it's declared in. I tried searching for it in the cement source code but I couldn't find the module which declares the error. I would like to know how to catch this error or if I should just set all the default app.config values before I parse a config file.

BJ Dierkes

@derks

import configparser
try:
    pass
except configparser.NoOptionError as e:
    pass

should work in theory

Dela Anthonio

@delaanthonio

I see. I didn't notice that configparser is in the Python standard library.

BJ Dierkes

@derks

It is, yeah

In generate, a lot of the interfaces/handlers in Cement are built on top of other libraries. Cement core has zero dependencies so most things are in Python Standard Library (Logging, ConfigParser, Argparse, etc)

AkhIL

@akhilman

@derks, take a look how plugins implemented in https://github.com/click-contrib/click-plugins and https://docs.openstack.org/developer/stevedore/. They are uses entry points from setuptools to automaticaly descover plugins

BJ Dierkes

@derks

@akhilman early versions of cement used entry points but there were issues with it, and I think Cement 2 was the first release that dropped it

maybe things have changed since then though

Craig Schlegelmilch

@cschlegelmilch

Hello, I was wondering if I could ask for some design advice. My project is essentially split into two version where there is a “regular” version and a “lite” version where the lite version is a subset of functionality of the regular. However, this doesn’t mean that the suite of commands differs, it means that the commands themselves do more in the regular version than the lite version. Is there a “Cementy” way of structuring this? I see that there is a plugin infrastructure that sort of checks off all of the boxes but is really does seem built for adding additional functionality, not overridding core functionality. Is that a valid description? Or am I just SOL and need to manage this myself?

BJ Dierkes

@derks

The commands are the same… but the arguments differ? What exactly differs?

and could you give an example?

Craig Schlegelmilch

@cschlegelmilch

For sake of argument, lets assume that commands are exactly the same. The difference is the behaviour/implemenation of the commands differs between the versions of the app

Essentially, I want to replace the functionality of an entire controller

BJ Dierkes

@derks

Literally replace (like two complete different controllers in code), or extend (build off of the lite version to add functionality)?

Craig Schlegelmilch

@cschlegelmilch

The later. If I was I talking in OO terms, I would want to inherit from the original controller and override the methods that define the commands

BJ Dierkes

@derks

Yeah, basically… this is maybe what I would look at… you have LiteController.some_command .. and some_command() would call _actual_code_of_some_command() … AdvancedController would inherit LiteController, but override _actual_code_of_some_command() ….

the interface to the end user is the same, but the logic differs

Craig Schlegelmilch

@cschlegelmilch

Am I able to package that up as a plugin? Or is that just the wrong question?

BJ Dierkes

@derks

you could also have some_command() call _some_command_lite() and _some_command_advanced() … and the AdvancedController would only override _some_command_advanced() (which would preserve the lite versions code, but do more things also)

You can definitely do a plugin. What I would try is, the plugin would import and subclass yourapp.whatever.controllers.LiteController … and then int he plugin’s load() function you would app.handler.register(AdvancedController, force=True) which forces it to register overtop of the LiteController (of the same label)

BJ Dierkes

@derks

assumes that LiteController.Meta.label and AdvancedController.Meta.label are the same, because it provides the same functionality

Craig Schlegelmilch

@cschlegelmilch

Ah. There’s the magic sauce (force=true). That’s what I was looking for. OK, cool. This makes sense.

BJ Dierkes

@derks

Awesome

Craig Schlegelmilch

@cschlegelmilch

Just as a sanity check, this isn’t going to break into a million pieces once v3 is out is it?

(I’m now starting to roadmap the migration to Python 3 and Cement 3)

BJ Dierkes

@derks

No no… most of the core api will be pretty well intact (loading plugins, etc). Especially if you build off of cement.ext.ext_argparse.ArgparseController

Craig Schlegelmilch

@cschlegelmilch

Which I am. Good stuff.

BJ Dierkes

@derks

Major design change will be things like from cement.core.foundation import CementApp will be from cement import App …

Simplifying usage

Craig Schlegelmilch

@cschlegelmilch

Nice. You know when its going to drop?

I promise not to hold you to it

Where communities thrive

People

Repo info

Activity