[TIP] Tox : Can I retrieve a project version from within tox.ini

Laurent Brack lpbrac at dolby.com
Wed Oct 22 09:13:32 PDT 2014

Hi Holger,

On 10/21/14, 10:08 PM, holger krekel wrote:
> Hi Laurent,
> On Tue, Oct 21, 2014 at 12:44 -0700, Laurent Brack wrote:
>>> On Tue, Oct 21, 2014 at 11:58 -0700, Laurent Brack wrote:
>>>> I was wondering if it was possible to retrieve a project version
>>> >from within tox other than by exporting it to an environment
>>>> variable prior to running tox.
>>>> something equivalent to export VERSION=`myproject --version`
>>>> I know that you can do something like {env:MY_VERSION:1.2} but this
>>>> requires that the version env. var is set prior to calling tox.
>>>> being able to extract this information during a tox run would be useful.
>>> In principle these lines work if you need a version from python code:
>>>      import pkg_resources
>>>      print (pkg_resources.get_distribution("myproject").version)
>> Thanks for the answer but I realize that perhaps I was really clear.
>> I meant within the tox.ini file itself. I wanted to avoid having to
>> wrap the tox call (see below).
>> Basically, I was looking for something in the tox specification
>> which would allow me to do this (not from python). This
>> ({env:MY_VERSION:1.2}) was an excerpt from my tox.ini which requires
>> me to export the version prior to calling tox or default to a
>> (hopefully) not too bogus value.
>> Sorry for the confusion
> Setting environment variables more dynamically requires some more shell
> like functionality (backticks for example) which tox does not have (yet?).
> Or we would need to introduce a specific option for calling
> a script and having it return a list of environment settings.
> If we had shell style backticks we could do:
>      setenv =
>          MYVERSION = `python -c ...`
> and everything would be fine.

If this is the only use case, perhaps this is an overkill. I think I can 
live with the method you suggested below (don't know where my head was 
yesterday :)

>>> If you for some reason can't do that you need to wrap what you call with
>>> a script that uses the above to set an environment variable before
>>> calling the script.
>> I wanted to avoid this. One of the reason is that this wrapper won't
>> be called by devpi test. In our tox files, we upload the xunit
>> report generated by pytest to a different test management system.
> I meant a wrapper around the command(s) that are in the "commands" section.
> So instead of:
>      commands = py.test ...
> you'd have
>      commands = python setenv.py PKG_I_WANT_VERSION_OF \
>                 py.test ...
Yup. That obviously works.

> You'd have to ship the setenv.py script and after setting
> the environment variable do a subprocess call with the remainder
> of the arguments.  Or am i still misunderstanding something?
>> There are more convoluted ways to do what I want to do but I was
>> hoping for a cleaner solution ... convolution always comes bite you
>> in the rear end eventually :).
> Software seldomly does exactly what we want it too or otherwise
> we'd all be out of work to do :)

Actually you cleared the convolution ... sometimes I feel (and this has 
nothing to do with tox) that some people I work with (and perhaps 
including myself) work hard on job security ... :)

> cheers,
> holger
best. Laurent

More information about the testing-in-python mailing list