Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    BJ Dierkes
    @derks
    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
    BJ Dierkes
    @derks
    from cement.ext.ext_argparse import ArgparseController, expose … will be from cement import Controller, ex … things like that.
    I’ve made a few of the major changes already… I’m actually focussig mainly on revamping the site and documentation
    I’m hoping for later this year
    I’m rewriting SphinxDoc to Markdown… it’s mostly just tedious work right now… then I will button up the major design changes I wanted to roll out
    p3j4p5
    @p3j4p5
    Hi everyone,
    I hope this is the right place to ask.
    I've started working on a project that is using the Cement framework and I would like to ask a few things.
    We are using a plugin that takes a number of config options.
    Those options get set in the expected place in: /etc/<project_name>/<project_name>.conf
    The question is, what is the most elegant way to retrieve the config options inside a plugin?
    I know it is possible to do something like: self.app.config.get('section', 'option') in the _setup function of the plugin but is there a way retrieve that information without invoking app?
    Didn't have much luck when reading the docs, so I would appreciate if someone could point me to the right place.
    Thanks,
    Paul
    BJ Dierkes
    @derks
    what is the reason for not wanting to invoke app?
    if it is simply because it is annoying to call self.app.config.get (understandable) you could create a shortcut like using get_section_dict
    like self.config = self.app.config.get_section_dict(‘my_plugin’) … then just use self.config[‘my_key’] through out your plugin
    @p3j4p5 ^
    p3j4p5
    @p3j4p5
    Thanks,
    The main reason is that app is only available in the `_seti
    The main reason is that app is only available in the _setup method.
    BJ Dierkes
    @derks
    actually, app is passed to the _setup() method … because that is called when the plugin is instantiated during app.setup(). You should set self.app = app in _setup() .. or if you subclass from cement.core.handler.CementHandler just make sure you super() in _setup() and it does that
    afte app.setup() you can access self.app anywhere in the plugin class
    p3j4p5
    @p3j4p5
    okay, thank you @derks! I will try that
    zero-signal
    @zero-signal
    Hi! Just getting to grips with the framework although have hit a stumbling block. Using cement 2.10.2 and following the BOSS app creation documentation. Created an app although when I run it it doesnt seem to load the example.py plugin module. Have not modified the BOSS app in anyway. Any thoughts? Can post debug output if that is any use?
    Checked for tickets relating to this on both cement and BOSS issue trackers but cannot see anything obvious
    Thanks in advance
    BJ Dierkes
    @derks
    @zero-signal have you setup a config file… usually ~/.yourapp.conf ?
    and I assume you used boss to create a cement-app and also cement-plugin? You need to configure plugin_config_dir and plugin_dir in a configuration file in order to find plugins..
    zero-signal
    @zero-signal
    @derks thabks for getting back to me. I ended up symlinking myapp/config/app.conf created by the boss cement-app to the location you suggested and the same for plugins.d conf directory. All is working well and I can start developing the app now. I mistakenly assumed after running setup.py develop that it would pick up the configs. Thanks for the help!