#PythonPackageBuildEnvironment ...
* pip-tools: https://github.com/nvie/pip-tools * "are there updates?" * "which updates would there be?" * devpi: https://bitbucket.org/hpk42/devpi/ * "where do we push these?" * "does it build (do the included package tests pass)?" "does it build (do the included package tests pass)?" * [Makefile], setup.py, tox.ini, travis.yml, dox.yml * https://github.com/pypa/warehouse * Src: https://bitbucket.org/pypa/pypi * https://westurner.org/tools/#pypi * Docs: https://westurner.org/tools/#python-packages ... " Re: [Distutils] Where should I put tests when packaging python modules?" https://code.activestate.com/lists/python-distutils-sig/26482/ > [...] > * https://tox.readthedocs.org/en/latest/config.html * https://github.com/docker/docker-registry/blob/master/tox.ini #flake8 * dox = docker + tox | PyPI: https://pypi.python.org/pypi/dox | Src: https://git.openstack.org/cgit/stackforge/dox/tree/dox.yml * docker-compose.yml | Docs: https://docs.docker.com/compose/ | Docs: https://github.com/docker/compose/blob/master/docs/yml.md *https://github.com/kelseyhightower/kubernetes-docker-files/blob/master/docker-compose.yml *https://github.com/kubernetes/kubernetes/blob/master/docs/user-guide/pods.md#alternatives-considered * https://github.com/docker/docker/issues/8781 ( pods ( containers ) ) * http://docs.buildbot.net/latest/tutorial/docker.html *http://docs.buildbot.net/current/tutorial/docker.html#building-and-running-buildbot tox.ini often is not sufficient: * [Makefile: make test/tox] * setup.py * tox.ini * docker/platform-ver/Dockerfile * [dox.yml] * [docker-compose.yml] * [CI config] * http://docs.buildbot.net/current/manual/configuration.html * jenkins-kubernetes, jenkins-mesos > /[..] On Wed, Nov 11, 2015 at 12:30 AM, Thomas Güttler < [email protected]> wrote: > Am 10.11.2015 um 21:54 schrieb Wes Turner: > > * It is [currently [#PEP426JSONLD)] necessary to run setup.py with each > given destination platform, because parameters are expanded within the > scope of setup.py. > > OK > > > > * Because of this, client side dependency resolution (with a given > platform) is currently the only viable option for something like this > > Are you sure that this conclusion is the only solution? > > A server could create a new container/VM to run setup.py. > > Then the install_requires can be cached (for this plattform). > > Maybe I am missing something, but still think server side dependency > resolution is possible. > > Please tell me what's wrong with my conclusion. > > > > > > > ... > > > > * Build: Docker, Tox (Dox) to build package(s) > > * Each assembly of packages is / could be a package with a setup.py > (and/or a requirements.txt) > > * And tests: > > * > http://conda.pydata.org/docs/building/meta-yaml.html#test-section > > * Release: DevPi > > * http://doc.devpi.net/latest/ > > * conda env environment.yml YAML: > http://conda.pydata.org/docs/using/envs.html > > * [x] conda packages > > * [x] pip packages > > * [ ] system packages (configuration management) > > > > And then, really, Is there a stored version of this instance of a named > Docker image? > > #reproducibility #linkedreproducibility > > I don't fully understand the above. > > I guess you had the container/VM solution in mind, too. > > There is a new topic in your mail which I will reply to in a new thread. > > Regards, > Thomas Güttler > > > -- > http://www.thomas-guettler.de/ > _______________________________________________ > Distutils-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
