import error in 19.1.0 #836

Closed
SaulTigh opened this Issue Aug 1, 2014 · 12 comments

Projects

None yet

4 participants

@SaulTigh
SaulTigh commented Aug 1, 2014

I've the following error:

Error: relative imports require the 'package' argument

No such error on previous installed version (19.0.0).

@benoitc
Owner
benoitc commented Aug 1, 2014

@SaulTigh hi, thanks for the ticket. Can you give more details? Do you have a way to reproduce it?

@SaulTigh
SaulTigh commented Aug 1, 2014

I've got this error with upgrade to 19.1.0 from 19.0.0.
I don't know if it helps, but I'm using supervisor for my django-project. Its configuration is:

[program:myproject]
command = /srv/myproject/env/bin/gunicorn myproject.wsgi:application -c ../conf/gunicorn/myproject.py
directory = /srv/myproject/myproject/
autostart = true
autorestart = true

And gunicorn configuration is:

NAME = 'myproject'
reload = False
bind = 'unix:/tmp/{basename}.sock'.format(basename=NAME)
pidfile = '/tmp/{basename}.pid'.format(basename=NAME)
daemon = False
keepalive = 2
import os
import multiprocessing
workers = 2 * multiprocessing.cpu_count()
# logging
PROJDIR = os.path.abspath(os.path.join(os.path.basename(__file__),  os.pardir, os.pardir))
accesslog = os.path.abspath(os.path.join(PROJDIR, 'logs/gunicorn/access.log'))
errorlog = os.path.abspath(os.path.join(PROJDIR, 'logs/gunicorn/errors.log'))
chdir = os.path.abspath(os.path.join(PROJDIR, 'myproject'))
pythonpath = chdir
@tilgovi
Collaborator
tilgovi commented Aug 1, 2014

@SaulTigh is there any traceback? Can you tell which import is causing it?

@berkerpeksag
Collaborator

I think the problem is at https://github.com/benoitc/gunicorn/blob/master/gunicorn/app/base.py#L101

I can reproduce it with the following command:

$ gunicorn -c ../c.py app:app

Error: relative imports require the 'package' argument

The error message comes from https://github.com/benoitc/gunicorn/blob/master/gunicorn/util.py#L87

And the related commit is 2bde8eb.

@tilgovi
Collaborator
tilgovi commented Aug 1, 2014

I had asked that we switch the order of these loads, so that relative file paths are tried before standard module imports.

Looks like @benoitc reverted that here: 46afb97

What was the problem you were seeing, @benoitc?

@benoitc
Owner
benoitc commented Aug 2, 2014

@tilgovi I think the change you were expected was done in #800. I reverted that changes since it was breaking module loading and forgot to come back on it right after.

The problem happen here because it try to load a module first for the config and just fail. Imo we rely too much on guess here (if we want to load a module or a patch) and we should probably do it more explicitely. I propose to do the following:

  • prefix by python: in case of a module. Ex: python:my.module.name
  • prefix by file: for the default. Ex: file:/path/to/configfile
  • Default case without prefix will be the file.

Thoughts?

@benoitc benoitc added the Bug label Aug 2, 2014
@tilgovi
Collaborator
tilgovi commented Aug 4, 2014

What about using the path separator or the file extension to guess:

Okay:

my.module
./my/module.py
./config.py

Bad:
./my/module
config (should be .config or ./config.py)
On Aug 2, 2014 1:20 AM, "Benoit Chesneau" notifications@github.com wrote:

@tilgovi https://github.com/tilgovi I think the change you were
expected was done in #800 #800.
I reverted that changes since it was breaking module loading and forgot to
come back on it right after.

The problem happen here because it try to load a module first for the
config and just fail. Imo we rely too much on guess here (if we want to
load a module or a patch) and we should probably do it more explicitely. I
propose to do the following:

  • prefix by python: in case of a module. Ex: python:my.module.name
  • prefix by file: for the default. Ex: file:/path/to/configfile
  • Default case without prefix will be the file.

Thoughts?


Reply to this email directly or view it on GitHub
#836 (comment).

@benoitc
Owner
benoitc commented Aug 12, 2014

@tilgovi it would break the current behaviour where you can pass config.py and then any graceful update. Imo the python module case should be an exception, so prefixing it looks ok for me.

@tilgovi
Collaborator
tilgovi commented Aug 14, 2014

👍 @benoitc

I nominate this for 19.2.

@lopopolo lopopolo added a commit to lopopolo/hyperbola-tools that referenced this issue Sep 3, 2014
@lopopolo lopopolo Remove . prefix for config to work around gunicorn issue 19f1a71
@benoitc benoitc added this to the R19.2 milestone Sep 22, 2014
@benoitc
Owner
benoitc commented Nov 23, 2014

what's the status of this one?

@tilgovi
Collaborator
tilgovi commented Nov 23, 2014

Free to take it. I probably can't this week.

@benoitc benoitc modified the milestone: R19.3, R19.2 Jan 29, 2015
@benoitc
Owner
benoitc commented Jan 29, 2015

I moved it to 19.3.

@berkerpeksag berkerpeksag closed this in #1068 Jul 9, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment