Prance depends on a now abandoned version of pyyaml

[cscutcher]

Apologies for not following the template but this is an odd situation that doesn't really fit.

The situation, as far as I can tell.

Quite rightly, in commit a2ba2c8, which went into 0.14.0, you bumped the version of PyYaml to ">4.0.0" which should include the safe secure behaviour for loading yaml. However there's been a fair amount of drama over in pyyaml's repo which you may have missed.

As far as I can tell from this ticket the maintainer got cold feet about the release of 4.x.x as it was a backwards incompatible change to load. They seem to have abandoned the 4.x.x releases up on PyPi.

The new release will be called 5.1 and I'll write up a "PyYAML 5.1 Release Plan" issue when the time is right.

There seems to be some suggesting that people use one of the failed 4.2bx releases to get #74 behavior. This is a bad idea. 3.13 is the current supported release. I could delete the 4.2b-s from PyPI but I haven't. I almost certainly will after 5.1 goes out.

Seems a bit crazy to me, but that's how things stand right now.

My problem and current workaround

This is causing me issues in my project using prance as pipenv is unable to resolve the requirement for a 4.x version of PyYAML as no officially released version of that package exists.

I am able to tell pipenv to consider pre-releases as well, but unfortunately that's a global option meaning that I'll get pre-releases for everything which causes more issues. It'd obviously be better if pipenv was able to more specifically target enable pre-releases (this is tracked in an issue on pipenv).

I am pretty sure I can work around that limitation in pipenv, but even if I do, given the maintainer seems to have abandoned the 4.x release, I'm not sure it's such a good idea.

For the time being I'll probably freeze prance to "<0.14" until the issue is resolved.

Request

That being said, if possible it seems like a good idea to go back to the old PyYaml version for the time being and it'd be awesome to see a new release of prance with that so I can unfreeze again.

Thanks for all the good work!

@jfinkhaeuser

[jfinkhaeuser]

Mhh, I did not consider pipenv, as I'm not using it. But that makes sense, of course.

How about we compromise? I've just subscribed to the PyYAML issue (been too lazy to before). If I bump a release before PyYAML 5.1 comes out, I'll go back to PyYAML 3.x - otherwise leave as is? You've already got a workaround, and I'm hoping this issue won't take much longer. Fingers crossed. Either way, I'll leave this issue here open to remind me!

---

As an aside, I'll have to look into pipenv at some point. I'm happy with my manual virtualenv workflow, but it seems that pipenv also honours setup.py's dependencies, so that should be ok.

[cscutcher]

Thanks for getting back to me and keeping an eye on it. I'll be watching how things develop too.

Pipenv is a still a little rough round the edges but is great for consistent deploys between prod, dev and test environments.
It makes managing updates for applications a great deal easier as well as secure for end users and it hopefully discourages package developers from over-specifying requirements. It also helps a lot diagnosing funky sub-dependency conflicts like this one. pipenv check and pipenv graph are both really handy. I see it as kinda the missing link for python dependency management.

Heads up though, while there are some genuine pain points from pipenv being relatively new, I'd say most of the time people use it for the wrong thing and suffer as a result. If you're going to give it a go I highly recommend reading this short section from the docs first.

Anyway thanks again. Have a good one!

[jfinkhaeuser]

WRT pipenv: yes, that section is what convinced me I might give it a try :)

If you look at prance's setup.py, you'll see that I take a fairly disciplined approach to declaring dependencies (PyYAML being the main exception, because of the above issue). In contrast the requirements*.txt are just conveniences for setting up a virtualenv.

[jfinkhaeuser]

So, 5.1b1 has been released. Let me see if I can bump a release with that, or have to wait for a non-beta (pip's version matching with these alphabetic version parts is a bit weird).

[jfinkhaeuser]

Tagged a 0.14.1 to get rid of the 4.x dependency, but I will tag a 0.15 when 5.1 final is released. Leaving this open for now.

[jfinkhaeuser]

0.15 is building with 5.1, and should be on pypi soon.