Skip to content

Category: Openpyxl

Goodbye BitBucket

Around 2008-2009, I had the chance to work together with Python pioneers at Logilab when at a customer.
They are great supporters of the Python ecosystem and used (at least then) Mercurial for all their code versioning needs.
Coming from a CVS/Subversion heritage, I quickly found Mercurial to be a vastly superior solution and embraced it enthusiastically.

As a result, in 2010, when I started to work on openpyxl, Mercurial was the obvious choice to me. At that time, git (boosted by the GitHub platform launched in 2008) was already growing fast and was the “popular” option. However, its arcanic CLI was a joke in comparison to the beginner-friendly, no-nonsense experience Mercurial was providing.

Finding hosting for the project was not easy, since while git experience itself was no fun, GitHub was really setting the standard for code hosting platforms. After a few experiments (including running my own repository, exploring GNU Savannah, Google Code, …) I finally settled with BitBucket.

The rest is part of openpyxl’s history, and while I often got told “WhY U No UsIng GiHUb??!”, mercurial was the VCS I knew the best, and as the main developer, it seemed to me that my efficiency was the main driver.

When Charlie joined on the project, and later took it over completely, he also shared the idea that the main developer experience is the most important, and remained attached to hg, and BitBucket as a result.

This era now comes to an end, with what Charlie describes, and I agree, as “an absolute disgrace” from Atlassian to sunset support of Mercurial in their hosting offering.

I’m no longer actively involved in the project, and while I keep it on my radar, I don’t yet know what are Charlie’s plans. From what I can see, Heptapod (founded by former Logilab and Mercurial core dev Pierre-Yves David and his pals at Octobus) could offer a way out. Combining Mercurial with GitLab would definitely be a great alternative, bridging the best hosting experience with the most robust VCS.

I’m really looking forward to Heptapod to gain the traction it deserves (while I also agree that GitHub got a significant head start, and developers seem to put hype before practicality nowadays).

Regardless of where Openpyxl will live on, I’m fully trusting Charlie to make the right call for the project, and will be updating this post once he has made a decision.

Comments closed

openpyxl repository change

Hi everyone, today I have decided to move the official openpyxl repository to a new location:

Why the change ?

Because I am no longer the main contributor on the project, and I felt that I did not have anymore the privilege to have the project tied to my sole name.

Also, as I’m not the only one to work on the project, I started to make pull requests and fork my own repository, which felt a bit awkward.

Finally, I hope that untying the project from me will encourage the growth of an ecosystem around openpyxl. I’ve already written a few tools based on openpyxl who have a live of their own (xlsx-diff for example), and I dream that more people start doing the same, and releasing them as open-source projects that could end up under the openpyxl umbrella.

Will I stay involved in the project ?

Of course, I’ll keep contributing features, based on user requests and needs I find in my daily work. I’m an avid openpyxl user, and most of my contributions solve issues I’m facing personally.

I’ll also keep advocating for openpyxl and its siblings, provide the CI infrastructure for openpyxl, participate in conferences, and write about the project.

Will the previous repository remain online ?

I’m keeping it online for the moment, as I’m sure that it is hardcoded in many people configuration files, makefiles, … but it will eventually be dropped for the reasons I mentioned at the beginning of this post.

My current timeframe is August 1st, 2014.

I have a fork, will I be able to merge it back to the new repository ?

I didn’t find the way to do it automatically using bitbucket, so what I did with my own forks was:

  1. checkout the fork on my laptop
  2. delete the fork from bitbucket
  3. make a new fork, with the same name, based on the new repository
  4. push my local repository to the fork
  5. make a pull request

Will it change again in the future ?

I don’t think so. We set up the openpyxl team on bitbucket, and Atlassian granted it with an academic licence, allowing for an permanent, unlimited amount of contributors.


1 Comment

openpyxl @ fosdem 2014

Thanks to Stéphane Wirtel and his team for all his hard work on the Python FOSDEM dev room which successfully demonstrates that you can pack 200 geeks in a room designed for 90 standing people maximum, every year.

(and hello to the poor guys who were left outside and had to watch my back through the window during the whole session)

Comments closed

Openpyxl 2.0.0

This is a very important milestone for the project as version 2.0.0 is now tagged. This means we are confident enough to have it tested in the wild, despite the few changes required to enjoy it fully (mainly in styles department).

As you might have noticed, even though we are sometimes backporting fixes to the lower release branches, development is going on 2.x branch now, and fixes are most likely to occur in the latest version.
We take tests and benchmarks seriously, so you are not on the frontline for bugfinding, hence we encourage you to get started with 2.x as soon as you can as this will become the new default version in a few days.

1.8.6 will remain our last 1.x branch, and will remain on PyPI for the moment, allowing a smooth(er) transition to 2.x. However, as we will focus our work on 2.x, do not expect changes to happen on that branch from our side, but feel free to contribute backports as pull requests if you need them on that version for a reason.

On a different note, I’d like to thank everyone involved on the project since its inception, in a few days from now, version 1.0 will be FOUR years old (see it here). I’d never expect this project to become what it is now, because I didn’t imagine there were so many nice contributors willing to give their time, energy, resources, to make an open source project succeed.
At last, I’d like to thank once more Charlie Clark for his devoted work, and for being our current champion at improving the ECMA standard ruling the OOXML format 😉 Good luck with that Charlie !


Comments closed

Upcoming changes for openpyxl

I’m announcing the last (or at least what I believe to be the last) 1.x release of openpyxl to be imminent. I’ll try to quickly fix all compatibility issues that arose since the last release so people can start using the development branch in other python versions than 2.7.5 …

2.x versions will then follow, starting with non-backward compatible changes in the styles department.

I’m also announcing I will no longer lead the project alone, as I can’t find as much time as I should to code, reply on the mailing list and review pull requests. For now, Charlie from Clark Consulting has accepted to help me on the 2.x serie.

Happy coding ! 🙂


Openpyxl 1.6.2 has been released

This is the first post-sickness release of the year ! \o/

Major changes include :

  • bugfixes (many)
  • improved documentation
  • new image inclusion support, using optional dependency on PIL
  • improved robustness for the charts module (still a work in progress, due to the size of the module)
  • data validation module

Once again, this is the release with the most external contributions so far, I’m really happy to see people interested in making the library go further, and providing such quality code, with tests and even documentation. I can’t thank you enough.

However, several pull request remain open, for various reasons from difficulty to merge with the current state of the code, to open question on the benefits of the change. Anyway, if a pull request didn’t make it into this release, it will probably be in the next 😉

Thank you as well for reporting issues you find on the bug tracker, the issues keep piling up so I still need as much help as possible to solve them, but that also means people are using the library 😉

I have now decided to stop using the Bitbucket Wiki page and instead use the ReadTheDocs documentation mini-site, which is better structured and more readable. I tried for a few hours to hide the wiki page, but it was only causing errors while installing openpyxl using pip, so I reverted my change and the wiki is still online for the moment, but won’t be updated anymore.

Here it is, don’t hesitate to give it a try and report errors if you find any 😉

Happy coding !


Why openpyxl development is stalled for now

I thought that I could communicate a bit more on why things haven’t seemed to move too much since my last announcement about how openpyxl development was going to rock in 2013.
In January, I turned 30, but I also became pretty sick, and what was first diagnosed as simple cold was in fact a severe viral disease, that left me and my liver in pretty bad shape. I’m now recovering from the virus (while my antibodies count is still hitting the ceiling) but for a whole month I was unable to focus for more than a few hours a day, and even then, only thanks to high doses of drugs to keep the fever at sustainable levels. I chose to invest all the time I had to do my day job and also to try my best to support my wife who is taking care of the kids (I unfortunately failed at the latter :-p).

I’m since then undergoing weekly blood analysis and have a MRI scheduled next month to see how bad my liver is and how to make it recover fully, and in the meantime I’m starting to feel better, but I’m definitely feeling like a cranky 80 years old man after 4PM, and this might last for a period ranging from a few weeks to a few months.

I’ll try to review as many pull requests as my strength enables me to in the coming days, but please bear with me, as everything will get in, but maybe not very fast 😉


openpyxl 1.6.1 is out !

First post-babies release, this is a “pull requests integration” release, plus a few fixes (including the infamous race-condition fix that was omitted in 1.5.8).

A huge effort has been put over several months to make this version work on 2.x and 3.x flavors of Python, and except a few broken tests (due to an incompatible test helper) you should be able to officially install and use the library on python 3 as of today.

I’ve noticed the important amount of open tickets on the bug tracker, and unfortunately my available time is shrinking those days due to family business 😉 I’ve set myself the goal to fix one ticket a week, which should keep me busy until 2014 (if nothing else breaks in the meantime). That’s why help is more than ever welcome on fixing bugs, and adding missing features; I’ll do my best to be more reactive in the future when it comes to pull requests (once again, all my apologies to all the great people who have submitted patches for the last six months and must have thought they would never hear a word from me).

Thanks again to all the contributors, especially the ones who have been kind enough to include unit tests in their patches, so I don’t have to spend time making sure they did not break anything ;-)Image

1 Comment

Installing Python 2.4 under Ubuntu 11.10 (Oneiric Ocelot)

As I’m currently merging 2.x and 3.x branches of openpyxl, I now need to perform tests over all existing Python releases known to man. I decided to install a new Ubuntu VM to perform the the tests, but I struggled during 2.4 installation.

Tried pythonbrew, which was a very disappointing experience as nothing worked as it was supposed to.

Then I tried to build from source myself, but here again the GCC version available on ubuntu 11.10 is apparently no longer able to compile original python sources.

Here is how I did it :

  1. download RPM version for Fedora here : (direct link)
  2. install alien (sudo apt-get install alien)
  3. type the following command
$ sudo alien -i python2.4-2.4-1pydotorg.i386.rpm

Now you can type

$ python2.4

and everything should work !

1 Comment

openpyxl 1.5.6

Small compatibility release this time, no big features added, see the changelog by yourself:

  • [iter_worksheet] add support for calculated strings (they have a special data type for that ?)
  • [strings] make sure we always use unicode strings everywhere
  • [iter] fixed max row and column detection for iter reader
  • [styles] fixed custom number format detection under OOCalc
However, a large effort has been made on supporting the whole python 2.4 – 2.7 range. In the past, 2.4 and 2.5 compatibilities were damaged, now it should be restored back to normal.
Once again, thanks to all the contributors for their help 😉