Unable to start new project with --template pro option
justice-rage opened this issue · 4 comments
Bug Description
When attempting to start a new Wagtail CRX project using the --template pro
option, the project creation fails, an empty project directory is created, and the CommandError: couldn't handle project template pro
error message is returned. This issue occurs despite the pro template being a valid option according to the Wagtail CRX documentation.
Steps to reproduce behavior
- Create a new virtual environment and activate it.
- Install coderedcms using
pip install coderedcms
. - Attempt to start a new project using the command
coderedcms start mysite --template pro --sitename "My Company Inc." --domain www.example.com
orcoderedcms start mysite --template pro
.
Expected behavior
A new Wagtail CRX project should be created with the pro template applied. The project directory should contain all the necessary files and directories for a Wagtail CRX project.
Actual behavior
The project creation fails with the error message CommandError: couldn't handle project template pro
. An empty project directory is created.
Additional context
The issue was encountered using Python 3.12.1 and coderedcms 3.0.2. The issue does not occur when starting a new project without the --template pro
option. The command coderedcms start mysite --sitename "My Company Inc." --domain www.example.com
works as expected and creates a new project with the default template. Thus, the Wagtail CRX basic installation works as expected. This suggests that the issue is specifically related to the pro template.
Workaround for 'pro' template issue
While the bug is being resolved, I found the following workaround to start a new project with the pro template:
- Create a new virtual environment and activate it.
- Install coderedcms using
pip install coderedcms
. - Clone the coderedcms repository:
This step is necessary to get the pro template files.
git clone https://github.com/coderedcorp/coderedcms.git
- Navigate to the directory containing the
pro template:
The pro template is located in theproject_template
directory within the coderedcms package. - Run the coderedcms start command with the
--template
option:
Specify the path to thepro
template. Replacepath_to_pro_template
with the actual path to the pro template in the coderedcms package.
coderedcms start mysite --template=path_to_pro_template --sitename "My Company Inc." --domain www.example.com
Thanks for reporting. I'm not able to replicate it, can you provide some additional info?
Operating system and version:
The full command you ran (starts with coderedcms start ...
):
Can you now run the same command above, but add --traceback
, and copy the output here:
Lastly, try creating a fresh virtual env, pip install coderedcms, then try running again.
Output of pip freeze
:
Of course. I've provided the requested information below. Made a dummy project called bugtest
for it. Let me know if you need anything else.
Operating system and version: macOS Monterey 12.7.2
The full command I ran: coderedcms start bugtest --template pro --sitename "bugtest" --domain www.bugtest.com
--traceback
Flag Output:
(venv) justice@Justices-MacBook-Pro bugtest % coderedcms start bugtest --template pro --sitename "bugtest" --domain www.bugtest.com --traceback
Creating a Wagtail CRX project called bugtest for bugtest (www.bugtest.com)
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.10/bin/coderedcms", line 8, in <module>
sys.exit(main())
File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/coderedcms/bin/coderedcms.py", line 177, in main
command.run_from_argv(sys.argv)
File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/django/core/management/base.py", line 402, in run_from_argv
self.execute(*args, **cmd_options)
File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/django/core/management/base.py", line 448, in execute
output = self.handle(*args, **options)
File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/coderedcms/bin/coderedcms.py", line 104, in handle
super().handle("project", project_name, target, **options)
File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/django/core/management/templates.py", line 149, in handle
template_dir = self.handle_template(options["template"], base_subdir)
File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/django/core/management/templates.py", line 249, in handle_template
raise CommandError(
django.core.management.base.CommandError: couldn't handle project template pro.
(venv) justice@Justices-MacBook-Pro bugtest % python3 --version
Python 3.12.1
As requested, I recreated a fresh virtual after deactivating and deleting the initial env
(I'm using venv
as the moniker in this case) I created for the bugtest dummy project's first command run. I then ran pip install coderedcms
then tried running it again with the same result.
pip freeze
Output:
(venv) justice@Justices-MacBook-Pro bugtest % pip freeze
anyascii==0.3.2
asgiref==3.7.2
beautifulsoup4==4.11.2
certifi==2023.11.17
charset-normalizer==3.3.2
click==8.1.7
coderedcms==3.0.2
decorator==5.1.1
defusedxml==0.7.1
Django==4.2.9
django-bootstrap5==23.3
django-eventtools==1.0.3
django-filter==23.5
django-modelcluster==6.2.1
django-permissionedforms==0.1
django-taggit==4.0.0
django-treebeard==4.7
djangorestframework==3.14.0
draftjs-exporter==2.1.7
et-xmlfile==1.1.0
filetype==1.2.0
future==0.18.3
geocoder==1.38.1
html5lib==1.1
icalendar==5.0.11
idna==3.6
l18n==2021.3
openpyxl==3.1.2
pillow==10.2.0
pillow-heif==0.14.0
python-dateutil==2.8.2
pytz==2023.3.post1
ratelim==0.1.6
requests==2.31.0
six==1.16.0
soupsieve==2.5
sqlparse==0.4.4
telepath==0.3.1
urllib3==2.1.0
wagtail==5.2.2
wagtail-cache==2.3.0
wagtail-seo==2.4.1
webencodings==0.5.1
Willow==1.6.3
It looks like something very strange is going on in your venv. The stacktrace with the error is showing python 3.10, but when you invoke python it is showing 3.12. Based on the paths in your stacktrace, it is not actually using the package from the venv, but is rather using the package which is installed at the system-level.
Try creating a fresh virutal env (use python -m venv /path/to/venv
). Then activate it and invoke python -m pip install coderedcms
. Once you are in the venv, confirm you are using the correct package by invoking which coderedcms
... the path should be a subdirectory of /path/to/venv/
The problem has been resolved and appears to have been a me issue. Just as you noticed this was due to a Python version mismatch.
Issue:
The coderedcms start command with the pro template was failing due to a Python version mismatch. The coderedcms command was linked to Python 3.10, while the virtual environment was using Python 3.12.1.
Using the which coderedcms
command it returned /Users/justice/Desktop/bugtest/venv/bin/coderedcms
. I ran python --version
and returned Python 3.12.1
. However when running head -1 $(which coderedcms)
it turns out the coderedcms
command was pointing to Python 3.10.
Solution:
The issue was resolved by ensuring that the coderedcms command was linked to the correct Python interpreter in the virtual environment. This was achieved by uninstalling and reinstalling coderedcms in a new virtual environment after deactivating and removing the previous one:
-
Activate the virtual environment:
source venv/bin/activate
-
Uninstall coderedcms:
pip uninstall coderedcms
-
Reinstall coderedcms:
pip install coderedcms
After these steps, the coderedcms start command with the pro template worked correctly as it was now linked to the correct Python interpreter (Python 3.12.1) which was verified using the head -1 $(which coderedcms)
command.
Strangely, I only updated to Python 3.12 after encountering this issue. So my assumption is the coderedcms
command was originally failing due to a Python version mismatch on my part I failed to notice or remedy. I must have not realized it like I didn't in this most recent example.
I appreciate your help a lot. I'm assuming this issue is good to close, but I'll leave that to you.