pycparser v2.09 released, project moved to BitBucket

December 27th, 2012 at 6:20 am

I’ve released version 2.09 of pycparser. In addition to numerous issue fixes, the two major changes for this release are:

  1. The pycparser project has moved to BitBucket from Google Code. It’s still available on PyPI as usual.
  2. The dependency on PLY has been folded, by carrying an appropriate version of PLY along with pycparser. I find this strategy makes testing and deployment much easier. So if you now create a clean installation of pycparser, you no longer need to install any prerequisites. If you’re just upgrading, worry not, pycparser will use its own PLY (due to relative imports).

Related posts:

  1. pycparser v1.06 released
  2. pycparser now supports C99
  3. pycparser v1.0 is out!
  4. Faking standard C header files for pycparser
  5. Implementing cdecl with pycparser

16 Responses to “pycparser v2.09 released, project moved to BitBucket”

  1. PaulNo Gravatar Says:

    Out of curiosity, why did you move pycparser from BitBucket to Google Code?

  2. dhunterNo Gravatar Says:

    Great to hear that, google code is a bad place for freedom nowadays, me for example can’t enter for being part of the evil axis. Cheers from Cuba.

  3. MajikNo Gravatar Says:

    This comment is unrelated to the blog entry it’s posted to. It’s about your blog in general, and book reviews in particular. I find your book reviews to be concise and interesting.

  4. elibenNo Gravatar Says:

    @Paul,

    It was the other way around, read more carefully :-) I moved it to Bitbucket because that’s where I keep most of my projects nowadays. pycparser is the last non-toy project I had hosted on Google code.

    @Majik,

    Thanks for your feedback.

  5. ripper234No Gravatar Says:

    I just wanted to ask why bitbucket and not github? :)
    I hardly recall seeing FOSS projected hosted there … github is where it’s at.

  6. DovNo Gravatar Says:

    It seems that the issue tracker is not public (I can’t find a link to the list of issues; and while the google code project was still functioning but already referenced issues at bitbucket, following the link to an issue on bitbucket said that I don’t have permissions to view the issues) — is this intentional?

    Regarding the folding of ply into pycparser — wouldn’t adding ply as a dependency have been enough? Have you looked into buildout (http://www.buildout.org)? (I have no experience with it, but it sounds interesting). I’m interested in hearing your considerations about this… Thanks!

  7. EventhNo Gravatar Says:

    It’s great that you moved it to Bitbucket, but did you disable issues on purpose? If so, maybe README.rst should mention how you want bugs reported? :)

  8. dhunterNo Gravatar Says:

    @Majik yes I found this blog years ago and I really enjoy the TATWD philosophy, one moment you’re reading high level python and the next an extremely dense c++.

  9. dhunterNo Gravatar Says:

    @ripper234 maybe is a matter of personal preference on mercurial over git.

  10. elibenNo Gravatar Says:

    The issue tracker is now enabled. Its previous disabled state was a mistake, of course.

    @Ron,

    I joined BitBucket a while ago because of Mercurial, which is my favorite SCM. It’s not that I’d mind switching to Git, but BitBucket now also offers unlimited private repositories which is very useful for me. AFAIK, that does not exist on Github for the unpaid accounts. FWIW I also have a Github account with some stuff (mainly forks).

    @Dov,

    PLY was previously marked as a dependency and it mostly worked fine. But it called for an additional step for those installing Python from source, and for myself when I wanted to perform specific manual testing routines. Most recently, the tox test-helper tool had some mixup with pip and ply for Python 3.x which wouldn’t let me test through it. This was the straw that broke the camel’s back. Things are much simpler now.

  11. elibenNo Gravatar Says:

    @dhunter,

    What is TATWD?

  12. dhunterNo Gravatar Says:

    @eliben Turtles All The Way Down, is a philosophy about understanding the things and its foundations to the core itself, is related to the ancient believing of the world being supported by four elephants and a turtle.

  13. Dirkjan OchtmanNo Gravatar Says:

    As someone who packages pycparser for a source-based Linux distribution (Gentoo), I really dislike the bundling. At a minimum, please keep track of what version of PLY you keep bundled in your tarballs (preferably in the README, or somewhere else which is easily found). Restricting your dependency to a specific version of PLY sounds like it might have been an acceptable solution which would make more sense from a distro point of view.

  14. elibenNo Gravatar Says:

    @Dirkjan,

    The PLY version is mentioned in pycparser/ply/LICENSE, but I now also placed it in the main README per your request.

    Why do you dislike the bundling? Because it takes up additional disk space? From my point of view, it makes testing pycparser distributions easier because I don’t need to run into obscure pip bugs with Python 3 which make it choke on installing PLY for me.

  15. Dirkjan OchtmanNo Gravatar Says:

    Bundling means our users have any number of copies of source code for any given package installed (one each for every project that decided to bundle it). Now, there might be some bad bug (possibly security-related), and instead of updating the canonical package and everyone relying on the fixed version, all the packages are still broken. From a distro point of view, bundled dependencies are less transparent and thus much harder to manage. On the other hand, making sure that our pycparser depends on a compatible version of PLY is fairly easy.

    I understand there’s currently a problem with installing PLY through pip, but I hope that wasn’t a big factor in this decision, as it seems like it should be a temporary failure.

  16. elibenNo Gravatar Says:

    @Dirkjan,

    I understand you point of view. However, for me as a developer bundling simply means less work in the long run, which is the tradeoff I have to choose. Moreover I believe that users can benefit from it also, because the version I release is stable, and will stay stable even if new, less stable versions of dependencies get installed. If there’s any critical error with PLY that affects pycparser, I will fix it very quickly. pip problems, tox problems, all kinds of problems made me waste a lot of time doing grossly un-interesting setup related work. Bundling is easier.

Leave a Reply

To post code with preserved formatting, enclose it in `backticks` (even multiple lines)