i have a problem running celery from the app "binary" after i installed it with logan.

as a test, i created a django project. runserver works fine. i can start the runserver and celery using

python manage.py runserver
python manage.py celeryd -E -B

after i installed the project, i am be able to start it.

eukalypse_now runserver

this is VERY awesome. however, i can not start celery

eukalypse_now celeryd -E -B
...
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/desch/.virtualenvs/empty1/local/lib/python2.7/site-packages/billiard-2.7.3.18-py2.7-linux-x86_64.egg/billiard/forking.py", line 502, in main
    prepare(preparation_data)
  File "/home/desch/.virtualenvs/empty1/local/lib/python2.7/site-packages/billiard-2.7.3.18-py2.7-linux-x86_64.egg/billiard/forking.py", line 642, in prepare
    file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named eukalypse_now

i am not sure if this is a problem in billiard handels something or in how logan created the binary. billiard only looks for the module in the ./bin path of the project in the virtualenv.

any idea?

I changed a few lines to make logan python3 compatible:

1. "print " --> "print("
2. "except Exception, e" --> "except Exception as e"
3. "raise ConfigurationError unicode(e), exc_info[2] " --> "raise ConfigurationError(unicode(e), exc_info[2])"
4. iteritems --> items
5. execfile is gone, I used http://stackoverflow.com/questions/436198/what-is-an-alternative-to-execfile-in-python-3-0

Also, I removed unittest2 because I couldn't get it to run in python3.

Do you like it? What can I improve?

raise ConfigurationError(unicode(e), exc_info[2])", "logan.importer.ConfigurationError: (u'cannot import name _uuid_generate_random', <traceback object at 0x7f4039597a70>)"]

At python 2.7 when trying to install sentry from ansible

I started investigating some faults, wanted to fix, then I came here and saw I had already investigated this before and done a pull request all the way back in May.

This has not been merged and a new release has not been put up on pypi.

Is this project dead? Why is that so? Do you want someone else to take over maintainership? I could do that, though I'd mostly maintain, not develop.

Hope everything is OK and there's not worse reasons for project being stale.

I really like the way sentry is structured and I was wondering if we could create a Django template or a Cookiecutter template where the project structure could be like sentry and packaging/distribution of the project becomes really easy and the project itself is an app that is standalone. Would love to hear your thoughts.

File "/usr/local/lib/python2.7/dist-packages/logan/importer.py", line 24, in <module>
    from django.utils.importlib import import_module
ImportError: No module named importlib

From Django sources:

warnings.warn("django.utils.importlib will be removed in Django 1.9.",
    RemovedInDjango19Warning, stacklevel=2)

Hi everyone,

I use logan for a project and logan generates a projectname.conf.py, cool. This behavior worked for us when the project was small. But now we have many more scenarios and I'd like to use logan to generate a "working directory" for me with the following content:

projectname.conf.py
nginx.conf
gunicorn.conf.py
Procfile

To do this I'd add another method like logan.settings.create_default_settings which could be executed after config was generated and is optional. Before I start implementing this I'd like to get some opinions.

Is this a good idea? How do you solve this problem in your projects? Is there a roadmap for logan?

The 0.5.10 build on pypi seems to have some errors in Python 3. It looks like this was fixed in #16, but a new version hasn't been released since then.

Any chance you could bump the version, so that we don't have to install from git on Python 3?

Hi!

I'm working on a FreeBSD port of Logan and noticed that the version currently rolled out through Cheeseshop (https://pypi.python.org/pypi/logan) depends on Django <1.5 and was released on 2013-09-30.

Could you please roll out a new version? Packaging PyPi libraries is much more convenient than depending on Github commit hashes (as there's no recent tag newer than 0.5.9.1).

Best, xmj

Your tests requirements require ''django>=1.2.5,< 1.5'', but sentry, which uses this package requires Django>=1.5.5. Can you do something like 'django>=1.2.5,<=1.5.5', so we can run automated tests for both packages? Thanks!

Hi, my name is lionel and I'm also a developer. I've noticed that you have the name "logan" for your project and I want to ask you if it's matter that one of my cli python tool project (https://github.com/first-developer/logan) is a also named "Logan" according to licensing. Thanks in advance for your answer.

Bests Lionel

Sometimes I need to add a middleware on the top or near the top. An example is the Debug Toolbar.

The order of MIDDLEWARE_CLASSES is important. You should include the Debug Toolbar 
middleware as early as possible in the list. However, it must come after any other middleware that 
encodes the response’s content, such as GZipMiddleware.

It's possible with logan?

Hi everybody,

logan works fine with django 1.8 for our project but we have one problem: pytest.

I'm not sure if this is a problem of pytest but I wanted to ask if anybody is using the combination of py.test and logan and django 1.8. Since the update we have an issue when we run the tests:

ImproperlyConfigured: Requested setting CACHES, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings.

We managed to integrate logan into pytest by defining a conftest.py with the following content:

from logan.runner import configure_app
from myproject.logan_runner import get_logan_kw
configure_app(**get_logan_kw())

But with the new version of either django or pytest or pytest-django something is wrong with the import ordering I guess.

I'm just curious if anybody experienced the same things and has a solution. Again, logan might work fine here so feel free to resolve this issue :)

When I run

$ myapp

I see

usage: myapp [--config=/path/to/settings.py] [command] [options]

But when I run

$ django-admin.py

I see

Usage: django-admin subcommand [options] [args]

Options:
  -v VERBOSITY, --verbosity=VERBOSITY
                        Verbosity level; 0=minimal output, 1=normal output,
                        2=verbose output, 3=very verbose output
  --settings=SETTINGS   The Python path to a settings module, e.g.
                        "myproject.settings.main". If this isn't provided, the
                        DJANGO_SETTINGS_MODULE environment variable will be
                        used.
  --pythonpath=PYTHONPATH
....

--> How do you guys feel about putting a small logan-header on top of the help message and run the help command by default?

With

def main(): run_app(settings_initializer='MY_CONF', ...)

When I call

MY_CONF="my.py" my test --stop

everything works fine but with

my --config=my.py test --stop

I get a no option "--stop" error. (I'm using the nose test runner)

Is that behavior expected?

Can the --config option be removed? The settings_envvar could be assumed to be there on start and that would also provide another benefit: When I initialize a new project I had to look into the code until I realized that "my init" required another parameter: the default config path --> If the settings_envvar would be required the error would be more clear I think.

Project argument is optional for configure_app.

And then project=None scripts crashed, after line 63.

https://github.com/dcramer/logan/blob/master/logan/runner.py#L63

I have a little library here at work (configtools) that helps me mange Django settings in config files and making a module kind of act like django.conf.settings by pulling config from some other preconfigured module (considering open-sourcing it, but that's beside the point). It makes use of something like sys.modules[name] to get access to the current module object at import time. Unfortunately, the way Logan handles the --config option and loading the file breaks that. This new option takes a dotted module name that gets passed almost directly to import fixing my problem.

I'd almost recommend replacing --config with --settings_module as, with my experience in the python community, most always you refer to a module or function in it's dotted form (e.g. package.module or package.module:function) when passing them as arguments to command line tools (see DJANGO_SETTINGS_MODULE, how you launch an app with gunicorn, etc...). This keeps backwards compatibility with --config and prevents both from being passed at the same time.