Stop pinning jinja2 versions about honcho HOT 9 CLOSED

👍 Just ran into this issue as well

from honcho.

I hear you, but I'm afraid it's pretty much fundamentally impossible to reliably install non-broken Python packages systemwide without explicitly pinning versions, and I don't see why Jinja2 should get special treatment just because Armin is a good maintainer.

The alternative is to release packages that are susceptible to bitrot (Jinja2>=2.7 will break when 3.0 is released) or to resort to nasty hacks like Jinja2>=2.7.0,<2.7.999 because setuptools/distutils don't have any sensible equivalent to Bundler/NPM's ~> syntax.

As it is, it's easy enough to bundle up Python packages in their own virtualenv, which makes pinned versions a non-issue. I highly recommend that if you're deploying Python packages systemwide, you install into a virtualenv. You might find https://github.com/jamescasbon/pypackage useful.

from honcho.

I don't think the argument is against pinning as much as it is against pinning when it doesn't effect the primary use case of honcho. The generation of other process manager scripts is a nice feature, but the core of the application is really starting processes and multiplexing the output. What is frustrating is to have an install break b/c of a dependency for a feature the majority don't use.

Have you thought about making the script generation an optional install?

$ pip install honcho[export]

That would avoid the issue on the majority of uses while still providing the feature.

from honcho.

Adding Jinja2 as an extras dependency is certainly something we can consider, but I think most people are pretty unfamiliar with setuptools extras, and Pip's support for them has historically been flaky. I hear you about the distinction between core and non-core dependency -- perhaps the best way to resolve this is to simply catch the ImportError in the export code and print a sensible error message informing the user that they must install Jinja2 to use it.

from honcho.

I hear you, but I'm afraid it's pretty much fundamentally impossible to reliably install non-broken Python packages systemwide without explicitly pinning versions

Doesn't that achieve the exact opposite? If I have package A requiring foo==1.2.3 and package B requiring foo==1.2.4 I can't install both, at all.

As it is, it's easy enough to bundle up Python packages in their own virtualenv, which makes pinned versions a non-issue. I highly recommend that if you're deploying Python packages systemwide, you install into a virtualenv.

That's exactly what I'm doing and what isn't working. Two packages with incompatible pinning will conflict, regardless of whether they are in the same virtualenv or system-wide. Unless you're suggesting I install honcho into its own virtualenv, in which case I need to have at least two virtualenvs per application now (and this wouldn't work for a library or any sort of heroku deployment).

from honcho.

I ran into the same issue. And yes we're using virtualenvs and all. I'd suggest to pin it to minor versions. e.g. >= 1.7 <= 1.8 for packages known to use the 3rd number as patch versions. Pinning so strictly for stable packages, does not protect you from installation non broken packages anyways. I think as soon as it starts to become unpractical, less strict pinning wins over not using the software at all. If you know some jinja version to be broken, maybe just excluding it in the pinning spec would work fine? And yes, if it's only for exporting stuff and not for essential functionality, I think making the dependency optional is a sensible way to go.

from honcho.

Any news on this?

from honcho.

Sorry this has dragged on for so long. I'm looking into this now. I'll move the jinja2 dep to a setuptools extra and make the failure to install a runtime error if you use the export command, much as @ionrock has done above.

from honcho.

Thanks @nickstenning!

from honcho.