@webknjaz helped me a lot on setting up deployment infrastructure for yarl and multidict projects.
His last contribution to multidict is amazing: we have MacOSX binary wheels for the project.
Take a look on https://pypi.python.org/pypi?:action=display&name=multidict&version=3.3.0#downloads
He is really The Travis Jedi!
Take a look on travis config for multidict project: https://github.com/aio-libs/multidict/blob/master/.travis.yml
Very complicated code.
I love to have the feature in aiohttp but hate to support the config.
Let's include Sviatoslav to our team as infrastructure engineer.
@webknjaz sure, you can work on everything on your mind but I hope to close any infrastructure problems by your nomination.
As usual:
-1 for strong objection.
+-0 for not sure.
+1 for positive vote.
The vote is closing in a week, at 2017-10-24.
+0
~+0~ (vote changed)
multidict .travis looks overly complicated for me. Would be nice to have some docs around to reduce time of understanding what's happens.
Now aiohttp/.travis.yml has the same complexity too.
That's because we want to build MacOSX binary wheels along with manylinux and Windows.
Most likely in a near future we'll add PyPy wheels too.
@webknjaz uses YAML substitution directives for reducing instructions duplication, otherwise the file will be 10 times longer and totally unmaintainable.
Unfortunately deployment of not pure python library is a pain.
Guys, I supported travis config for years, Sviatoslav started to help me about 4 months ago.
I very appreciate his help and will be happy to receive his contributions in future.
A right to push tags for alpha releases is required for testing all improvements in deployment.
Otherwise I should check all @webknjaz PRs myself by making non-prod releases before merging.
That's how our deployment procedure works.
About documentation -- it would be nice to have but I doubt if it is the first priority.
Travis commands are documented on their site, anchors and aliases are described in YAML spec: http://yaml.org/spec/1.2/spec.html
But feel free to ask concrete questions about non-obvious config parts.
+1 for someone else working on travis because I'm very happy it's not my responsibility.
@asvetlov I believe they in fact implement a limited subset of YAML1.1: https://github.com/travis-ci/travis-yaml
@kxepal my current goal is to create some automation around it, so that nobody would need to try understanding that mess :)
@webknjaz Try to look on Hypothesis project. They have very rich and complex CI with continuous deployment and automated all the things, but at the same time their build toolchain is pretty clear and simple to read, understand and reproduce localy.
@asvetlov
Don't get me wrong, I feel positive on your initiative! I just hardly get what exactly travis will do with such a config. Nothing personal, I don't have builtin YAML parser yet (: I feel it could be simpler, but wouldn't block @webknjaz to help make things better.
I wish it was that simple :)
@kxepal hypotesis is pure python project, that's it.
Deployment of binary wheels is much more complex procedure.
Other projects use custom toolchain with private boxes for deploying but we do it on travis and appveyor without payments or hosted servers.
The price is complicated configuration.
Maybe later we'll setup jinja generator for keeping templates simple but extending all needed steps for bots. We discussed it with @webknjaz briefly. But now the life is hard, sorry.
PyPy wheels
That's unlikely: AFAIK for this we'd need to have CFFI, not cython. This is where pure source distribution would fit.
Let's discuss PyPy on #2342
+1
Done.
Welcome, @webknjaz !
馃帀 @webknjaz 馃帀
^_^ Feels like a b-day gift :)
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a [new issue] for related bugs.
If you feel like there's important points made in this discussion, please include those exceprts into that [new issue].
Most helpful comment
+1 for someone else working on travis because I'm very happy it's not my responsibility.