1 new commit in tox:
https://bitbucket.org/hpk42/tox/commits/cb509b4c25c3/
Changeset: cb509b4c25c3
User: Oliver Bestwalter
Date: 2016-06-24 16:11:02+00:00
Summary: organize the notes a bit
Affected #: 1 file
diff -r f1d3efa85f12ae0c460eb68b26eceaac2e13b294 -r
cb509b4c25c3dee2be78c39591f65de25e1058be
doc/drafts/extend-envs-and-packagebuilds.md
--- a/doc/drafts/extend-envs-and-packagebuilds.md
+++ b/doc/drafts/extend-envs-and-packagebuilds.md
@@ -1,75 +1,54 @@
# Extension of environment handling and building packages
-Goal drive building of packages and the environments needed to test them,
exercising the tests and report the results for more than just virtualenvs and
python virtualenvs
+*Notes from a discussion at the pytest sprint 2016*
-Necessary to implement:
+Goal: drive building of packages and the environments needed to test them,
exercising the tests and report the results for more than just virtualenvs and
python virtualenvs
-* sdist refactoring (con concept for multiple package creations (e.g. wheels,
conda, ...))
-* environment system extension
+### Problems
-## Use case: conda
-
-* general package def (how to build the package)
-* general environment def (how to build an environment)
-* matching environments to package definition (at package definition level)
(e.g {py27,py34}-{venv,conda,pyenv}-[...])
-
-## Problems
-
-* package definition that might match on everything might be a problem for
which environments test? Not clear?
-* sdist would need a "sdist" factor to only be matched against virtualenvs
-
-## section examples
-
-envlist={py,27,py34}-{win32, linux}-{conda,virtualenv}
-
-[packagedef:sdist]
-# how to build (e.g. {py27,py34}-{sdist})
-# how to match (e.g. {py27,py34}-{sdist})
-
-[packagedef:conda]
-# how to build (e.g. {py27,py34}-{conda})
-# how to match (e.g. {py27,py34}-{conda})
-
-[packagedef:wheel]
-# how to build
-# how to match
-
-## Next release (3.0)
-
-* ship what we have
-* Plan for next major release
-
-## sdist refatoring
-
-* Needs concept of mapping environments to specific packages (versioned
packages)
+* No concept of mapping environments to specific packages (versioned packages)
* no control over when it happens for specific environment
* no control over how it happens (e.g. which python interpreter is used to
create the package)
-* trigger it only if an environment actually needs it
+* No way of triggering build only if there is an environment that needs a
specific build trigger it only if an environment actually needs it
+* package definition that might match on everything might be a problem for
which environments test? Not clear?
-### Ideas
+### Solution
-* Simplify for the common case: most packages are universal, so it should be
simple
-one to one relationship from environment to directory
-* Floris: metadata driven. Package has metadata to the env with what env it is
compatible
-* Holger: configuration driven. explicitly configuring which packages should
be used (default sdist to be used, overridable by concrete env)
-* Ronny: "package definitions" (this pacakge, this setup command) + matching
definitions (matching packages (with wldcards) for environemnts)
+It should be possible to build other kinds of packages than just the standard
sdist and it should also be possible to create different kinds of builds that
can be used from different environments. To make this possible there has to be
some concept of factorized package definitions and a way to match these
factorized builds to environments with a similar way of matching like what is
in place already to generate environments. sdist would for example would match
to a "sdist" factor to only be matched against virtualenvs as the default.
-## integrate detox
+This could then be used to hae virtualenv, conda, nixos, docker, pyenv, rpm,
deb, etc. builds and tie them to concrete test environments.
+
+To summarize - we would need a:
+
+ * packagedef (how to build a package)
+ * envdef (how to build an environment)
+ * way of matching envs to concrete packages (at package definition level)
(e.g `{py27,py34}-{win32,linux}-{venv,conda,pyenv}-[...]`)
+
+## Beginnings of configuration examples (not thought out yet)
+
+ [tox]
+ envlist={py,27,py34}-{win32, linux}-{conda,virtualenv}
+
+ [packagedef:sdist]
+ # how to build (e.g. {py27,py34}-{sdist})
+ # how to match (e.g. {py27,py34}-{sdist})
+
+ [packagedef:conda]
+ # how to build (e.g. {py27,py34}-{conda})
+ # how to match (e.g. {py27,py34}-{conda})
+
+ [packagedef:wheel]
+ # how to build
+ # how to match
+
+#### integrate detox
* reporting in detox is minimal (would need to improve)
* restricting processes would be necessary depending on power of the machine
(creating 16 processe on a dual core machine might be overkill)
* port it from eventlets to threads?
-## Extend environment integrations
-
-Different kinds and combinations of environments
-
-* Virtualenv, conda, nixos, docker, pyenv, rpm, deb, npm ...
-* Code needs to change a lot
-* need to be documunted properly
-
-### conda integration
+### Concrete use case conda integration (started by Bruno)
* Asynchronicity / detox not taken into account yet
* Conda activation might do anything (change filesys, start DBs)
@@ -77,19 +56,11 @@
* Packages would need to be created (from conda.yml)
* Activation is a problem
-### pyenv integration
-* ?
+### Unsorted discussion notes
-# Questions
-
-* list all environments from command line (not just the ones from envlist)
-
-# Ideas
-
-* sync command line options and actual documentation
-* General way of running tests in an already existing environment
-
-# Problems
-
-* Per python version wheels are not taken into account yet
+* Simplify for the common case: most packages are universal, so it should be
simple
+one to one relationship from environment to directory
+* Floris: metadata driven. Package has metadata to the env with what env it is
compatible
+* Holger: configuration driven. explicitly configuring which packages should
be used (default sdist to be used, overridable by concrete env)
+* Ronny: "package definitions" (this package, this setup command) + matching
definitions (matching packages (with wildcards) for environments)
Repository URL: https://bitbucket.org/hpk42/tox/
--
This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.
_______________________________________________
pytest-commit mailing list
pytest-commit@python.org
https://mail.python.org/mailman/listinfo/pytest-commit
