To add sugar on top, the packages that are already monitored for it, point you to that same guide, see it in action.
Who cares what a style guide says regarding indentation, dependencies, string quoting, docstrings, handling i18n, etc etc if then one can freely commit changes that go against the said style guide?
Talk is cheap
I’ve been putting as much effort and free time as I could to make that happen.
plone.recipe.codeanalysis has been improved1, flake8 plugins have been written, and finally during this last Alpine City Strategic Sprint 2016 I could implement the missing piece: report back to the users (see an example)!
The script is fairly simple:
#!/usr/bin/env bash wget https://raw.githubusercontent.com/plone/buildout.coredev/5.0/bootstrap.py -O bootstrap.py wget https://raw.githubusercontent.com/plone/buildout.coredev/5.0/experimental/qa.cfg -O qa.cfg wget https://raw.githubusercontent.com/plone/plone.recipe.codeanalysis/master/.isort.cfg -O .isort.cfg python bootstrap.py -c qa.cfg bin/buildout -c qa.cfg bin/code-analysis
Run the above on any Plone distribution and see the output collected on parts/code-analysis/flake8.log
Currently only a few packages are checked, but cleanup tasks can start on any Plone package as of now. Be sure to ask for a job that will check that the package remains clean as soon as your cleanup changes are merged!
This past five days I had the pleasure the be part on the last Plone sprint: Alpine City Strategic Sprint 2016, what a blast!
In the following days, the amazing never running out of steam, Jens will report back to the community. A partial/preview report already exists for the impatient ones (disclaimer: I made it, so there’s probably quite a few things missing).
Below I will make a summary of what I achieved thanks to being part of the sprint.
Fortunately all the above took less than one or two hours, my main task during the sprint was, together with Maik, bring collective.indexing in Plone core without having to add yet another package2. Please read the PLIP description, linked above, to know the scope of it.
As of now we are down to one single test failure! We are highly appreciated on creative ways to solve that last one…
A sprint is way more than just sitting in front of a laptop and coding!
Lots of interesting discussions where held, we had lots of fun, we did some sightseeing and enjoyed being together.
And after that I can only say that Plone’s future is brighter than ever has been!
As a personal pet peeve, we finally agreed (?) on how to sort imports! :-)
Last words go to Jens and Christine for taking so much care on preparing everything and being so open and helpful at any time, thanks!
I’m glad you asked, because there’s plenty of them, for example these ones:
There a step by step tutorial on the first message and plenty of packages to choose from.
World Plone Office Day is 3 weeks away only so, whether you are hosting one office day or you are thinking of to attend it, be sure to get a list of easy tasks to do for newcomers.
It probably happened to you, dear reader, every now an then: the new feature you are working on has changes across more than one git repository, so how can this be tested to make sure nothing is broken before merging those nth separate pull requests?
Let us know if it does not work as expected!
Now with Mockup he have the other side of the coin as well: we can not only check how the code integrates within Plone but we can also check its logic with fast unittests.
There’s already Travis integration for Mockup and Mockup-core (a building block for Mockup), but as Plone is using Jenkins it makes a lot of sense to run them there as well.
So, how that’s done? I’m glad you ask, exactly like this:
All the code is there, the last three pull requests are pending to be merged.
P.D: remember that tomorrow is WPOD!
This Friday Mai 29th we are celebrating the 2nd edition of WPOD!
Look around your city, meet with friends, make new ones and contribute to Plone!
As usual IRC will be full of contributors willing to help smooth your path into Plone, so don’t be shy and ask ;)
See you there/in IRC!
Did you ever got tired waiting a repository (managed by mr.developer) to be cloned?
Wait no more! mr.developer 1.32 comes with two new options to make your life easier:
What’s the benefit of this? See it for yourself:
git clone https://github.com/plone/buildout.coredev.git test-full du -sh test-full 36M test-full git clone https://github.com/plone/buildout.coredev.git --depth=1 test-shallow du -sh test-shallow 1,5M test-shallow
That’s a 24x saving.
So think about your CI environments where they are downloading over and over the whole repository information while you only care about the very last changes.
Think about some remote environments (mobile connection while you are on a train?)
Update: it seems that is completely broken, sorry for that, working on a fix.
Update 2: mr.developer 1.33 released, thanks @fschulze for the new release!
Maybe everyone is already aware of them, but just in case…
zc.buildout is THE building block that assembles Plone together.
It’s been around for quite a while (+10 years) and it has plenty of features.
Two of them which I’m enjoying a lot lately are:
./bin/buildout install code-analysis
install allows you to override which parts are going to be installed and thus it allows, like in the example above, reduce the amount of packages to fetch and things to build. Which for something like jenkins.plone.org can make quite a lot of sense to use it more and more.
annotate outputs the complete configuration that buildout will use as if it was everything in a single file. This is great for debugging “why my configuration is overriden or not being used at all” kind of errors.
Last Friday the first WPOD happened around the globe.
Here is what was done on the Berlin gathering:
Hopefully other participants around the globe will share their achievements as well!
Are you already planning the next WPOD? Mark it on your calendar May 29th.