[13:27:33] <malinoff> but pip install -e . fails with "error in button-cli setup command: 'install_requires' must be a string or list of strings containing valid project/version requirement specifiers"
[13:37:45] <ronny> malinoff: pip style requirements are not supported in setup.py?
[13:43:38] <ronny> malinoff: not sure a bout how to solve in detail (i'd just use a devpi and upload every commit as a .dev version)
[13:44:18] <nedbat> ronny, mathieui: malinoff tried using dependency_links as the docs say, with no success. I've never used dependency_links, do you have an example that works?
[13:44:46] <malinoff> ronny, well, i want travisci to work, so devpi is not even a solution in my case
[13:45:04] <mathieui> nedbat, no, I never tried it
[13:45:23] <mathieui> If my software needs something not in the cheeseshop, then it’s not stable enough to go on the cheeseshop, I guess
[13:45:56] <ronny> mathieui: cant travis use a devpi index server for dependency installs?
[13:46:12] <malinoff> mathieui, i'm developing bot button and button-cli at the same time; button is stable enough, but i'm playing with different options and solutions
[13:53:25] <malinoff> so if you look at make/invoke/doit docs, they spend a lot of time explaining how to declare tasks and how to run them from a shell
[13:53:51] <malinoff> and almost no time explaining how to run tasks from the python
[13:54:56] <ronny> so bascially you want to clear the python side
[13:54:58] <malinoff> the second one is they have lots of concepts (like pre_tasks, post_tasks, etc), but they're really "extensions"
[13:55:39] <malinoff> let me explain a little bit further please :)
[13:56:02] <ronny> bascially i want to figure where this makes sense, and how it can be extended uppon (thinking about things like an internal deploy tool, tox, devpi)
[13:56:03] <malinoff> so they have a lot of concepts in their core, but at the same time they're really not extensible at all
[13:58:51] <malinoff> but why we tied with remote execution?
[13:59:25] <malinoff> why can't we have such smart execution locally without code for daemonization, transport layer etc
[14:00:04] <malinoff> and here is my general idea - take the best from celery and build an extensible task execution framework
[14:00:24] <malinoff> in such way so it will be able to be extended for remote execution, for example
[14:01:37] <malinoff> this "extensible" concept was used even for command line interface
[14:02:03] <malinoff> the default implementation is quite verbose, like button -E tasks apply build
[14:02:21] <malinoff> but one can write a make-like cli implementation, e.g. bake build
[14:04:06] <malinoff> to summarize, button is a) general-purpose task framework with nice programming api, b) extremely extensible, so almost everything is possible and c) it has a very tiny codebase, so it is very easy to test, to install and to use
[14:05:31] <malinoff> of course, there's more, but my current english skills do not allow me to express them in adequate time frame :(
[14:06:09] <malinoff> nedbat, thanks, i'll try that
[14:14:08] <malinoff> that's not our case, unfortunately
[14:14:13] <ronny> bascially it comletely streamlines a partcula flow, which is upload all deps, make a venv for a version, unpack that, reconfigure the supervisor
[14:14:16] <malinoff> we have lots of servers without ssh access
[15:02:49] <malinoff> and it is nice that coverage is the standard, so when I moved from nose to py.test, coverage stuff just keep working
[16:26:25] <malinoff> ronny, one more thing - i take testing seriously, i test button on linux, osx and windows automatically using TravisCI and AppveyorCI :) you won't find this in other similar projects
[16:43:36] <ronny> malinoff: its quit unfortunate all those things require git, i much prefer mercurial