-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable installing catchpy into an existing Django project #4
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a big PR but it actually looks like this was fairly straightforward, which is awesome. Mostly a lot of moving files around and namespacing packages?
Thanks for the documentation updates - may need to add some more around publishing this to PyPi when we get to that point? The work with custom profiles is also helpful, and good catch with the UTF decoding.
We should check with @nmaekawa on how we want to set up PyPi publishing and versioning for the project - is 2.7.0
the correct bump?
Install as a Django app | ||
----------------------- | ||
|
||
Add to your `requirements.txt`: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to set these up directly as requirements, so that if you add the CatchPy package it will install these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call; in fact, this is already the case but the package dependencies aren't pinned.
catchpy/__init__.py
Outdated
@@ -1,3 +1,3 @@ | |||
# important to use single quotes in version string | |||
# for post-commit tagging | |||
__version__ = '2.6.0' # transfer_instructor endpoint | |||
__version__ = '2.7.0' # transfer_instructor endpoint |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe update or remove the comment?
@pytest.mark.usefixtures('js_list') | ||
@pytest.mark.django_db | ||
def test_to_annotatorjs(js_list): | ||
for js in js_list: | ||
catcha = AnnoJS.convert_to_catcha(js) | ||
anno = CRUD.create_anno(catcha, catcha['creator']['name']) | ||
js_back = AnnoJS.convert_from_anno(anno) | ||
assert AnnoJS.are_similar(js, js_back) | ||
# @pytest.mark.usefixtures('js_list') | ||
# @pytest.mark.django_db | ||
# def test_to_annotatorjs(js_list): | ||
# for js in js_list: | ||
# catcha = AnnoJS.convert_to_catcha(js) | ||
# anno = CRUD.create_anno(catcha, catcha['creator']['name']) | ||
# js_back = AnnoJS.convert_from_anno(anno) | ||
# assert AnnoJS.are_similar(js, js_back) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The goal here is to deprecate anything with AnnoJS? Or why is this commented out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For me, this test wouldn't pass before or after my changes so I'm not sure what to do and I forgot about it. Thanks for highlighting it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. We can check with Naomi maybe? I think we should deprecate the AnnoJS stuff as it is unused at this point IIRC, but not sure what the best timing for that is.
…into django-package
Make the requirements.txt more flexible, so other applications can more easily incorporate Catchpy.
3.12 was failing to install (pointing at old beta). Could move to a GHA matrix strategy instead of tox.
Update requirements
Replacing pytz with ZoneInfo from Python's standard library as Django 5.0 deprecates pytz.
prime_profile should be parent_profile Improves error handling of the receiver handler. The old handler was simpler but made some assumptions about the existence and state of the prime_consumer attribute.
3.8 is EOL in October but easy enough to support it until then.
Django 5 fixes
Instead of using tox, use a build argument to control the Python Docker base image to take advantage of GHA parallel / matrix strategy. We end up with multiple containers but they should build faster and be easier to debug than having to manage multiple versions of Python and PATH in one image.
Conditionally import ZoneInfo; use GHA matrix strategy
Change Summary
This PR restructures the Catchpy so that it can continue to be run as a standalone Django app but makes it possible to install Catchpy into an existing Django application.
anno
andconsumer
into the project directory:catchpy
. This makes is easier to package Catchpy into a Python wheel.consumer.Profile
toconsumer.CatchpyProfile
to avoid clashes with existing projects.local.txt
is default, butdocker-compose.yml
specifiesdev.txt
, which enables running tests directly in the dev container.setup.py
topyproject.toml
packaged a distribution with hatchurlpatterns
so that the admin URLs are only included when running as a standalone app and the others can be included in an existing project.token
detailsCatchpyProfile
one to one relationship exists before attempting to access it.Checklist