coveralls
commented
8 months ago coverage: 100.0%. remained the same when pulling 26a91081ab904661c0325b30901306f44fd0d2ed on django-4/5 into 86d955abf32d10db5678973049eb2f78801326ee on main.
Closed sdc50 closed 7 months ago
coveralls
commented
8 months ago coverage: 100.0%. remained the same when pulling 26a91081ab904661c0325b30901306f44fd0d2ed on django-4/5 into 86d955abf32d10db5678973049eb2f78801326ee on main.
sdc50
commented
8 months ago This is working fine with Django v5.0, however I do get this warning on startup:
/conda/envs/tethys-django-5/lib/python3.12/site-packages/django/db/backends/utils.py:98: RuntimeWarning: Accessing the database during app initialization is discouraged. To fix this warning, avoid executing queries in AppConfig.ready() or when your app modules are imported.
warnings.warn(self.APPS_NOT_READY_WARNING_MSG, category=RuntimeWarning)I haven't looked into it, but I expect that our app harvesting process would have to be overhauled to comply.
sdc50
commented
8 months ago I've unpinned django, channels, and daphne in the environment files, and added django-recaptcha. django-simple-captcha, and django-analytical as pip installs in the full environment.yml.
This means that the default behavior will be to install the latest version of Django. I think that's okay, but we should discuss how to handle this. We could build two different versions of tethys (tethys-django4 and tethys-django5), or we could just add some documentation specifying how to install with a specific version of django (e.g.):
conda install -c conda-forge tethys django=4.2That would probably require modifying the gen metayaml command to not pin django, or to pin it to be something like django>3.2<5.0.
swainn
commented
8 months ago That would probably require modifying the
gen metayamlcommand to not pindjango, or to pin it to be something like django>3.2<5.0.
What do you think about moving to a “minimum” version requirement with some logic in our code to handle specific problems with each minor version? The minimum could be the current LTS.
sdc50
commented
8 months ago What do you think about moving to a “minimum” version requirement with some logic in our code to handle specific problems with each minor version? The minimum could be the current LTS.
That seams reasonable. I was hoping to make this a Tethys 4.3 release, so I feel like it should still be compatible with Django 3.2.
sdc50
commented
8 months ago I'm looking into the django-analytical feedstock. This is what I get when trying to install it from conda-forge with django 5.0:
I'm not sure why it's going back to django v3.2. It says it requires greater than 2.2. But I wonder if the Python pin is the issue. It says python <=3.6. I think it should be python >=3.6.
requirements:
host:
- python <=3.6
- pip
run:
- python <=3.6
- django >=2.2Although, I've got an environment with django-anaytical 3.1.0, django 3.2.20, and python 3.12.0, so I'm not sure what's going on.
sdc50
commented
8 months ago @swainn do you mind putting in a PR to the django-analytical feedstock? I think we just need to fix the python dependency.
Encountered problems while solving:
- nothing provides python <=3.6 needed by django-analytical-3.1.0-pyhd8ed1ab_1
Also, I can't see the see why the builds are failing on the django-simple-captcha feedstock. I'm wondering if you can since you are a maintainer: https://github.com/conda-forge/django-simple-captcha-feedstock/pull/8
swainn
commented
8 months ago @swainn do you mind putting in a PR to the
django-analyticalfeedstock? I think we just need to fix the python dependency.Encountered problems while solving:
- nothing provides python <=3.6 needed by django-analytical-3.1.0-pyhd8ed1ab_1
Also, I can't see the see why the builds are failing on the
django-simple-captchafeedstock. I'm wondering if you can since you are a maintainer: conda-forge/django-simple-captcha-feedstock#8
Can do. I'll take a look at both of those.
swainn
commented
8 months ago @sdc50 the django-analytical MR was created and merged.
The workflow that is failing is called "webservice" and this is the error:
swainn
commented
8 months ago @sdc50 the django-analytical MR was created and merged.
The workflow that is failing is called "webservice" and this is the error:
Here's the full log for the re-render job:
sdc50
commented
8 months ago This is what the meta.yml file looks like when using the -p minor option (the default when building a release package).
requirements:
build:
- python
- setuptools
- setuptools_scm
run:
- python=3.12.*
- pyopenssl=24.0.*
- openssl=3.2.*
- django=5.0.*
- channels=4.0.*
- daphne=3.0.*
- setuptools_scm=8.0.*
- pip=24.0
...conda must handle python differently, because even though it's pinned, I can still install an environment with tehtys-platform=4.2 and python=3.10. However, I cannot install tethys-platform=4.2 and django=5.0 or django=2.2.
So, if we want the same tehtys-platform package to work with multiple versions of django then I think we'll nee to handle the pinning that package separately.
sdc50
commented
8 months ago Oh yeah! We already have a way to handle special cases when pinning packages in the meta.yml file. It's to pin them in the environment.yml file.
requirements:
build:
- python
- setuptools
- setuptools_scm
run:
- python<3.3
- pyopenssl=24.0.*
- openssl=3.2.*
- django>=3.2,<6
- channels=4.0.*
- daphne=3.0.*
- setuptools_scm=8.0.*
- pip=24.0When I build the environment locally it resolves to Django=5, but the CI is resolving to Django=4.2.11. I'm not sure why it's different.
passes tests with django 3.2, 4.2, and 5.0 Still need to refactor recaptcha template