Hi Christian, On 08/24/2015 03:52 PM, Christian Hammond wrote: > pip's removed support for dependency_links, requiring that all package > dependencies be made available on PyPI. This means there's no way we can > host a build of this ourselves, have a project depend on it, and build > the project as a package. It simply will ignore our builds and fail with > a dependency error (assuming a version range of >=1.6.11.1,<1.7). (If > installing from source, it looks like requirements.txt can still specify > links, but that doesn't help when building/distributing wheels/eggs.)
Yes, I'm afraid you're trying to solve an additional problem I didn't realize you had, because I didn't realize ReviewBoard was distributed as wheels/eggs. In general, my feeling has been that Python packaging is not well suited to distributing deployable web apps, and they are better distributed as source (with requirements.txt) plus installation instructions. I think pip's developers feel similarly, and are aiming for a clear distinction between setup.py "abstract" dependencies and requirements.txt "concrete" ones. (See e.g. https://caremad.io/2013/07/setup-vs-requirement/, authored by Donald Stufft, the primary pip maintainer.) So the official line is that if you need to get _that_ specific about dependency versions (and especially if you're needing to source those versions off-PyPI), you should be distributing a requirements.txt file, not a wheel or an egg. Obviously there's nothing stopping you from doing that -- just have your ReviewBoard setup.py depend on ``Django>=1.6,<1.7``, and then strongly recommend to your clients that they have a ``requirements.txt`` file with a ``--find-links`` line referencing your Django 1.6 unofficial support downloads page in order to get the latest security-patched versions. But that doesn't allow you to automatically enforce that all the consumers of your wheels/eggs will actually do this. [snip non-functional workaround] > The only other option I can think of is to actually upload the 1.6.11.x > build to PyPI under a different name ("beanbag-django16", for instance), > but keep the top-level module as "django". This will inevitably cause > conflicts with the officially installed Django package, though. Not a > good option. Nope, not great. > So at this point, it seems that while we can maintain security backports > of Django 1.6.11, we can't realistically depend on them or trigger > upgrading to them. Short of the official Django package on PyPI either > hosting our backports or registering URLs to them, there might not be a > clean way to do this. I'm pretty sure is not the route you guys want to > go for this, though. I don't really think that's an option. At that point they'd have to be officially supported, because there's no longer any opt-in required to get them. > Any ideas on alternative ways to tackle this? I'm officially stuck. I'm afraid I don't have any solution to offer, other than embracing the "abstract vs concrete" dependencies distinction, and accepting the fact that users of your wheels/eggs are choosing to be more "on their own" when it comes to their chosen dependency versions. Carl -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/55DB9CAA.3090108%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
