After over a month of work I've finally released version 0.3.0 of pyramid_fullauth! This release changes are mostly to testing the package, as with it, it finally reached 100% code coverage, but along I also introduced automatic style checking with pep8, pylint, pep257 and mccabe linter, so in-code changes were big enough, that I had to release it as a new minor version.
Some time ago, I decided to refactor pyramid_fullauth tests from mostly unittest style (though run by py.test) to same factor function style tests and base them on pytest_pyramid package, when it comes to test webapp. Everhything went smoothly, until I stumbled upon SQLAlchemy session in tests.
Elasticsearch is all the buzzwords recently. There are projects using it to fast distributed search, as a document database and as a tool for data analysis. I've wanted to check out Elasticsearch for some time already, even more, since I've been at lecture about aggregations in Elasticsearch by Honza Král at PyConPL 2013 . I recently got a chance to check it out migrating project from whoosh to elasticsearch. And first thing I noticed about Elasticsearch from solutions I've been using so far are analyzers.
Everyone might have a hard time to keep his code clean, shiny according to pep8, and not to mention that there are other extensions to ` pep8 <http://legacy.python.org/dev/peps/pep-0008/>`_ rules, like pyflakes, or other linters for that matter. Of course, each linter can be installed, but imagine the need to run each separately, to determine what's in your code that should be fixed. Here comes Pylama.
I've just released pytest_pyramid, a package, that should help testing pyramid applications with pytest suite. It's mostly generalized code, that I've been using across my projects to create both configuration and testing application.
This third SQLAlchemy speed tests for various dialects is my third try, prompted by Tony Locke. Tony is a contributor to pg8000 postgresql connector, which just recently got a huge overhaul and got a new version, after almost three years. I was happy to comply, as his request got me reason to work a little bit on my testing script as well, and automate the whole process.
I've just released new version of tzf.pyramid_yml. For toally new thing foir this package, I Licensed it under MIT License. Apart from that it introduces few enchancements in terms of defining config location.
Sometimes when you develop, you might find yourself with strange error. It says that the process you're trying to start is trying to use port, that is already being used. It's strange, because it is usually You, who used this port on previous run. If that's the case, then fuser command should relieve you from this error.
The k parameter is responsible for actual killing. Without it, the command would just identify which process is using port/socket in question.