Package Conflicts With Django-Simple-Captcha

[artforlife]

Because both django-simple-captcha and django-recaptcha contain all their files in a directory called captcha, there is a way to create a conflict. In particular, if someone uses one of these projects as the captcha tool explicitly, whilst also using another package that uses the other project (captcha tool), pip can override the captcha directory with the unwanted package during installation.

Precisely this happened to me when I tried to put a Django project into Docker. Locally it works fine. However, inside the Docker container, pip overrides the captcha directory with the competing package.

mbi/django-simple-captcha#217

requirements.txt example

django-cms>=3.7,<3.8
djangocms-admin-style>=1.4,<1.5
django-treebeard>=4.0,<5.0

djangocms-text-ckeditor>=3.7,<3.9
djangocms-link>=2.5,<2.6
djangocms-style>=2.2,<2.3
djangocms-googlemap>=1.3,<1.4
djangocms-snippet==2.3
# djangocms-video>=2.1,<2.3
djangocms-file>=2.3,<3.0
djangocms-picture>=2.3,<2.4
djangocms-bootstrap4>=1.5,<1.6
easy_thumbnails
django-filer<=1.7
Django<=2.2.14
django-classy-tags>=0.9
django-sekizai>=1.0,<=2.2.0
django-mptt>0.9
html5lib>=1.0.1
Pillow>=3.0
six
pytz

aldryn-forms==4.0.1
pytils==0.3
django-modeltranslation==0.15
django-rosetta==0.9.4
psycopg2-binary<=2.8.6
django-ckeditor-filebrowser-filer==0.3.0

faker==4.1.0
yandex-checkout==1.6.0
yandex-translater==6.0

django-analytical

django-recaptcha==2.0.6
django-debug-toolbar==2.2

djangocms-attributes-field<=2.1.0
#django-sekizai<=2.2.0
typing_extensions==4.1.1
importlib-metadata==4.8.3
django-classy-tags==2.0.0

[Andrew-Chen-Wang]

this would require a major version upgrade to change the package import name

[artforlife]

this would require a major version upgrade to change the package import name

I am just a messenger.

On another note and for what it is worth, I have discovered that the thing above only happens in venv environment. When I use a Conda environment, it works. In Conda, I still use pip install to get the Python packages. Hence, it might be a Pip vs. Conda issue, but the two captcha packages still do carry this potential for a conflict.

[Stormheg]

Any suggestions for alternative package names?

I'm inclined to say 'why does django-simple-captcha not rename their package to simple_captcha' but I might be overly biased as I'm one of the maintainers of this package 😉

[hedleyroos]

This package does predate django-simple-captcha, so in all fairness django-simple-captcha introduced an accidental collision. In an ideal world this one would have been called recaptcha, and the other one simple_captcha.

[koutoftimer]

@Stormheg

Any suggestions for alternative package names?

What about django_recaptcha ?

I guess, anything that is not the same as something you can get from django packages for "captcha" will work.

Here is a list of names that are already in use "captcha", "drf_recaptcha", "hcaptcha", "simplemathcaptcha", "hcaptcha_field", "friendly_captcha", "snowpenguin"

A lot of them are outdated and I have listed them just in case some will revive.

[mbi]

This package does predate django-simple-captcha

It really doesn't. Django-simple-captcha was first released on PyPI a good year before the first release of django-recaptcha. 🤷‍♂️

[Stormheg]

Fixed in 6385e21

This will be released as a breaking change in v4.0.0