https://pantsbuild.org/ logo
Join Slack
Powered by
Hey all! I'm working on migrating a repository to ...
# pex
l
Hey all! I'm working on migrating a repository to pants and have run into some issues with pex I could use some help on. Namely, I'm trying to package a Django application. In Django, you need to run a configuration step before you can do anything else. I am doing this at the top of my entry_point script, but it appears that pex actually imports a ton of files before the entry_point, causing this initialization to not be complete. Does anyone here have experience packaging Django applications with pex?
h
@happy-kitchen-89482 you started to look into better documenting Django and Pants/Pex, right? Does this ring a bell?
@loud-lizard-41405 are you getting a Django runtime error?
l
The classic 
ImproperlyConfigured
exception
Even though 
manage.py
is set as my entry point, it appears that my models are being evaluated first, which results in django not being configured yet.
I would have thought that a pex was just a fancy wrapper around 
python manage.py
but that doesn't appear to be how it is actually executing. I put a print at the top of my 
manage.py
as well as my model files and I can see pretty conclusively that files other than the entry point are being evaluated first which is totally unexpected.
h
Oh! Try setting 
zip_safe=False
..Alternatively, 
execution_mode='venv'
, which should also net you better performance
l
No dice on 
zip_safe
No dice on 
venv
either, still running out of expected order
Alright, I got it figured out. Still not really the behavior I would expect, but I got it to work. For reasons I won't get into, our 
manage.py
script lives in a module which has an 
__init__.py
script. What appears to be happening is that even though 
manage.py
is the explicit entrypoint, 
__init__.py
is executed first which causes things to break. As a dummy hack, I import an empty function from 
manage.py
into 
__init__.py
to ensure it is run first.
👍 1
👀 1
Is there documentation around how a pex file actually gets invoked? Everything I read made it sound more or less like a pex was a wrapper for 
python entry_point.py
which isn't the case.
h
https://pex.readthedocs.io/en/latest/, but I'm not sure if that's what you're looking for Generally, there is work to be done on docs with 
pex_binary
, including mentioning the new 
execution_mode
thing we added recently but haven't yet had the time to document
e
@loud-lizard-41405 if you're using Pex directly you want --venv. If you're using Pants you want pex_binary.execution_mode = "venv": https://www.pantsbuild.org/docs/reference-pex_binary#codeexecution_modecode That should net you a venv plain and simple which comes closest to the environment your django app would normally run in I assume.
➕ 1
Ah, saw just scanned your 
__init__.py
bit. But wouldn't that be a problem in any execution environment?
Sorry - scanned this all poorly, looks like you've covered all this ground. The question about init.py still stands though. Its not clear to me how PEX would be special here.
Aha. So, PEX is effectively running 
python -m myapp.manage
not 
python myapp/manage.py
. Presumable 
python -m myapp.manage
would give you the same troubles as PEX.
🙌 1
l
Ah, yep, that would do it
e
PEX would have to offer a new entrypoint style where it: 1. Always unzipped the PEX no matter the execution mode. 2. Executed the specified entrypoint (file) directly. It does not have this today.
I'll file a feature since Django is - consternating here - but clearly very useful and this is a super common use case.
👍 1
I think that gets this right and would work for Django CLI apps in general.
l
So our situation is admittedly a bit weird, manage.py isn't usually in a module
I have another CLI app that works just fine where the entry point is not in a module
h
FYI we're archiving this channel based on a plan to streamline this Slack workspace, so if you need to follow up on this issue, please repost to #general . Sorry for the inconvenience!
Open in Slack
PreviousNext
Powered by