Hi Pkl, Sorry for slow reply, but I thought this was worth it:
On 03/09/14 20:45, Pkl wrote: > Concerning the "rules of open source", I've yet to find a satisfying way > to apply them regarding these "micro breaks". Imagine that project > "myvideoplugin" is unmaintained (not handling PR) : unable to patch the > original Repo, I'd have to fork it ; and unable to push results to the > original pypi name, I'd have to create a separate myvideoplugin-pkl > package on Pypi... that's quite some hassle for (often) a 10-lines patch. There is no need to create a new pypi package and release - you can install straight from github like this: pip install git+git://github.com/foo/bar.git@abcde12345 You can put this straight into your requirements.txt as well. I have dozens of instances of this in my requirements.txt files. The trick then is to get your changes merged upstream. That is not always very easy - you have to be willing to genuinely contribute upstream i.e. contributions that make the maintainer's life easier, not harder. That means writing unit tests, or bootstrapping use of tox so that the test suite can be easily run against multiple versions. It might even mean starting a test suite because upstream didn't have one - in which case you also should reassess the process by which you choose dependencies... However, I've generally found that with effort and *genuinely helpful* upstream contributions, my PRs are accepted, and I can go back to using a PyPI release after some time. When I can't, it's because the upstream dependency wasn't solid, and it kind of serves me right for not being more careful and adding something to my project that wasn't reliable. In some cases I might have to take over being maintainer of the project - which is a burden, but part of the price you pay for being a part of the open source world and getting tons of amazing quality software for free. I do agree that we should be more careful about finding and documenting ways of doing deprecations so that libraries can support both old and new versions without generating deprecation warnings. I've just added one fix to 1.6 release notes on this front. Regards, Luke -- "Cross country skiing is great if you live in a small country." (Steven Wright) Luke Plant || http://lukeplant.me.uk/ -- 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 firstname.lastname@example.org. 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/542D3182.3050201%40cantab.net. For more options, visit https://groups.google.com/d/optout.