test_pure
Aaron S. Meurer
Aaron Meurer
Ondrej Certik
> What are the test_pure and test_pure_plotting executables for? They seem to be old (they call Python 2.4), and they require Debian (they use apt-get), so I can't run them. These need to be either updated, or removed if they are not needed anymore.
"test_pure" is supposed to test that sympy only requires pure Python
to run the whole test suite. I used a small installation of Debian, to
test this. There are other options to test this too, for example
installing Python from source and making sure PYTHONPATH is set
properly and so on. That is probably a better way to do it.
"test_pure_plotting" is supposed to test that plotting works. That I
would just remove, because I think we should use pyglet externally,
and also matplotlib for plotting.
Ondrej
Ronan Lamy
Aaron S. Meurer
I agree about the plotting. I am going to create an issue for this, and mark it a milestone for the next release (0.7.1).
Aaron Meurer
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
Aaron S. Meurer
Renato Coutinho
On Fri, Jan 7, 2011 at 9:40 PM, Aaron S. Meurer <asme...@gmail.com> wrote:
> Well, I can't run it because it uses Debian packaging. If you know how to rewrite it using tox or virtualenv, that would be great. I have never heard of those, but they sound promising.
I was checking tox, it really is very easy to use. All you have to do
is put a tox.ini in the main folder (along setup.py) with the content:
[tox]
envlist = py24,py25,py26,py27
[testenv]
commands=python bin/test
and run tox from that folder, and it will build a virtualenv for each
python version, install sympy from scratch on each and run the tests.
All the files are placed into a .tox folder. For those unfamiliar to
virtualenv (http://virtualenv.openplans.org/), it copies the python
binary to a different place and changes the paths to libraries so
that, running from that location, you have an almost isolated
environment (no system python modules). Also, things installed in the
virtualenv are restricted to that environment, so it's easy to have
several versions of modules installed side-by-side without hassle.
The setup required is: install tox (easy_install tox or pip install
tox) and be sure to have the several python versions installed on your
system.
This is a more general solution than maintaining a shell script
specific for debian distributions, although the installation of all
the python versions may be non-trivial depending on the
system/distribution.
Renato Coutinho
Aaron S. Meurer
On Jan 12, 2011, at 1:26 AM, Renato Coutinho wrote:
> Hi,
>
> On Fri, Jan 7, 2011 at 9:40 PM, Aaron S. Meurer <asme...@gmail.com> wrote:
>> Well, I can't run it because it uses Debian packaging. If you know how to rewrite it using tox or virtualenv, that would be great. I have never heard of those, but they sound promising.
>
> I was checking tox, it really is very easy to use. All you have to do
> is put a tox.ini in the main folder (along setup.py) with the content:
>
> [tox]
> envlist = py24,py25,py26,py27
Do you know if it is possible to test in different architectures. i.e., there are quite often SymPy bugs that only occur in 64-bit or 32-bit Python, so we need to test both.
Also, we need to test gmpy ground types. How do I ask it to install gmpy in each system? Assumedly we could have it run the tests under each ground type just by prefixing SYMPY_GROUND_TYPES=gmpy/python in the commands section.
>
> [testenv]
> commands=python bin/test
It should be ./setup.py test (which also runs the doctests), but yeah.
>
> and run tox from that folder, and it will build a virtualenv for each
> python version, install sympy from scratch on each and run the tests.
> All the files are placed into a .tox folder. For those unfamiliar to
> virtualenv (http://virtualenv.openplans.org/), it copies the python
> binary to a different place and changes the paths to libraries so
> that, running from that location, you have an almost isolated
> environment (no system python modules). Also, things installed in the
> virtualenv are restricted to that environment, so it's easy to have
> several versions of modules installed side-by-side without hassle.
>
> The setup required is: install tox (easy_install tox or pip install
> tox) and be sure to have the several python versions installed on your
> system.
Should tox be installed in each Python version, or only one? Anyway, I guess I will find out when I try it tomorrow.
>
> This is a more general solution than maintaining a shell script
> specific for debian distributions, although the installation of all
> the python versions may be non-trivial depending on the
> system/distribution.
Well, I already have all Python's installed, as do likely most SymPy developers, because we always have to test in all versions and there are very often bugs that manifest themselves in only one version or one architecture. And, of course, our build-bots will have all installed. Is this a good choice for a build-bot?
>
> Renato Coutinho
>
Aaron Meurer
Renato Coutinho
>> [tox]
>> envlist = py24,py25,py26,py27
>
> Do you know if it is possible to test in different architectures. i.e., there are quite often SymPy bugs that only occur in 64-bit or 32-bit Python, so we need to test both.
I think it is, if you have 32-bit python installed. It could go like this:
[tox]
envlist = py24,py25,py26,py27,py27-m32
[testenv]
commands = python setup.py test
[testenv:py27-m32]
basepython=/opt/pym32/bin/python
commands = python setup.py test
> Also, we need to test gmpy ground types. How do I ask it to install gmpy in each system? Assumedly we could have it run the tests under each ground type just by prefixing SYMPY_GROUND_TYPES=gmpy/python in the commands section.
You can specify dependencies, too, for example
[testenv]
deps = gmpy
commands =
SYMPY_GROUND_TYPES=python python setup.py test
SYMPY_GROUND_TYPES=gmpy python setup.py test
will install gmpy (from pypi) and run the tests with both python and
gmpy ground types.
> Should tox be installed in each Python version, or only one? Anyway, I guess I will find out when I try it tomorrow.
No, only one is enough.
>>
>> This is a more general solution than maintaining a shell script
>> specific for debian distributions, although the installation of all
>> the python versions may be non-trivial depending on the
>> system/distribution.
>
> Well, I already have all Python's installed, as do likely most SymPy developers, because we always have to test in all versions and there are very often bugs that manifest themselves in only one version or one architecture. And, of course, our build-bots will have all installed. Is this a good choice for a build-bot?
I don't know. AFAIK it does only what I described, ie, build
virtualenvs and run the commands. The site describes how to integrate
it with Hudson, though.
>> Renato Coutinho
>>
>
> Aaron Meurer
>
Aaron S. Meurer
On Jan 12, 2011, at 10:23 AM, Renato Coutinho wrote:
> On Wed, Jan 12, 2011 at 7:11 AM, Aaron S. Meurer <asme...@gmail.com> wrote:
>>> [tox]
>>> envlist = py24,py25,py26,py27
>>
>> Do you know if it is possible to test in different architectures. i.e., there are quite often SymPy bugs that only occur in 64-bit or 32-bit Python, so we need to test both.
>
> I think it is, if you have 32-bit python installed. It could go like this:
>
> [tox]
> envlist = py24,py25,py26,py27,py27-m32
>
> [testenv]
> commands = python setup.py test
>
> [testenv:py27-m32]
> basepython=/opt/pym32/bin/python
> commands = python setup.py test
>
>> Also, we need to test gmpy ground types. How do I ask it to install gmpy in each system? Assumedly we could have it run the tests under each ground type just by prefixing SYMPY_GROUND_TYPES=gmpy/python in the commands section.
>
> You can specify dependencies, too, for example
So if I also want to test it in pure Python (no dependencies), do I need two tox.ini files?
Aaron Meurer
>
> [testenv]
> deps = gmpy
> commands =
> SYMPY_GROUND_TYPES=python python setup.py test
> SYMPY_GROUND_TYPES=gmpy python setup.py test
>
> will install gmpy (from pypi) and run the tests with both python and
> gmpy ground types.
>
>> Should tox be installed in each Python version, or only one? Anyway, I guess I will find out when I try it tomorrow.
>
> No, only one is enough.
>
>>>
>>> This is a more general solution than maintaining a shell script
>>> specific for debian distributions, although the installation of all
>>> the python versions may be non-trivial depending on the
>>> system/distribution.
>>
>> Well, I already have all Python's installed, as do likely most SymPy developers, because we always have to test in all versions and there are very often bugs that manifest themselves in only one version or one architecture. And, of course, our build-bots will have all installed. Is this a good choice for a build-bot?
>
> I don't know. AFAIK it does only what I described, ie, build
> virtualenvs and run the commands. The site describes how to integrate
> it with Hudson, though.
>
>>> Renato Coutinho
>>>
>>
>> Aaron Meurer
>>
>
Renato Coutinho
>
> On Jan 12, 2011, at 10:23 AM, Renato Coutinho wrote:
>> You can specify dependencies, too, for example
>
> So if I also want to test it in pure Python (no dependencies), do I need two tox.ini files?
That's one way. Another is to create more envs:
[tox]
envlist = py24,py25,py26,py27,py27-pure
[testenv]
deps = gmpy
commands =
SYMPY_GROUND_TYPES=python python setup.py test
SYMPY_GROUND_TYPES=gmpy python setup.py test
[testenv:py27-pure]
basepython=python2.7
commands = python setup.py test
If you want to test with and without gmpy in all python versions, it
looks like there will be a lot of copy-paste to do. I saw in some
discussion they were planning some way to make this kind of thing less
repetitive, I have to check.
Renato
Aaron S. Meurer
And I won't mind a little copying and pasting. The painful thing will be waiting for the tests to run 20 times. :)
But this is way better than my present method, which is an enormous bash alias that runs tests in all Python's and ground types.
Aaron Meurer
Renato Coutinho
> OK, one more question. I have 32-bit and 64-bit installs of all Python versions (except for 2.4). But the paths to these are unique to my machine. Do you have any way to recommend that I could set it up so that I could add the .ini file to the git repo and still have it work with my specific python paths, and also so that other people could set it up for their python paths? Maybe I should require that people set the environment variables PYTHON26_32 or something like that? Is there some kind of precedent on that that you know of?
I searched a bit and found no one with a similar setup. I agree that
each user will end up putting the binaries in different places, so
it's better to not use your specific path. I would feel comfortable
with calling simply a "python2.7_32", or something like that, so I
would only have to add a symlink with that name to some place in my
$PATH. An environment variable would do the job too.
Renato Coutinho
Aaron S. Meurer
Actually, it looks like if it is given a Python path that doesn't exist, it just fails for that env and continues, so that may be a suitable workaround.
Aaron Meurer