Well, after more discussions with kparal, we are still unsure about the "right" way to tackle this. Our current call would be: 1) sync requirements.txt versions with fedora (mostly done) 2) allow --system-site-packages in the test_env 3) do `pip install -r requirements.txt` (with possible flags to enforce versions) to the makefile virtualenv creation step 4) add info to readme, that testing needs installation of packages from pypi, and that some of them need compilation 4-1) put together a list of packages that need to be installed (the python-foobar kind, not -devel + gcc) to the system, in order to "skip" the stuff that needs to be compiled
Sounds reasonable, Kamil? Others? Joza On Mon, Feb 6, 2017 at 2:11 PM, Kamil Paral <kpa...@redhat.com> wrote: > > 3. use a separate virtualenv when running under `make test`, without > --system-site-packages if possible, and ensure up-to-date deps are always > installed, to eliminate any differences that can occur on different setups > > The only problem I see here, is that some of the packages that you'd need > to install into the test-virtualenv need some C-compilation when installing > from PyPi, and that (if used without the --system-site-packages) would mean > having to install not only gcc but also plenty of -dev packages. > Not a _huge_ ussue but an issue nevertheless. > > > That's a good point. But do we have a good alternative here? If we depend > on packages like that, I see only two options: > > a) ask the person to install pyfoo as an RPM (in readme) > b) ask the person to install gcc and libfoo-devel as an RPM (in readme) > and pyfoo will be then compiled and installed from pypi > > Approach a) is somewhat easier and does not require compilation stack and > devel libraries. OTOH it requires using virtualenv with > --system-site-packages, which means people get different results on > different setups. That's exactly what I'm trying to eliminate (or at least > reduce). E.g. https://phab.qa.fedoraproject.org/D1111 where I can run the > test suite from makefile and you can't, and it's quite difficult to figure > out why. > > With b) approach, you need compilation stack on the system. I don't think > it's such a huge problem, because you're a developer after all. The > advantage is that virtualenv can be created without --system-site-packages, > which means locally installed libraries do not affect the execution/test > suite results. Also, pyfoo is installed with exactly the right version, > further reducing differences between setups. The only thing that can differ > is the version of libfoo-devel, which can affect the behavior. But the > likeliness of that happening is much smaller than having pyfoo of a > different version or pulling any deps from the system site packages. > > > Sigh, OTOH Josef has a very good point in https://phab.qa.fedoraproject. > org/D1112#20744 that figuring out which devel packages are needed on the > system for pypi module compilation is quite a non-trivial task. Seems > harder than figuring out which packages you need to install on the system > when using --system-site-packages. > > So, I don't really see a simple solution here that would guard us from > inconsistent dev setups (system site packages) or not require us to have a > painful deps maintenance (no system site packages, but devel packages) :/ > > Even if we decide to keep --system-site-packages for simplicity, I can > implement all the rest of the proposed improvements. Just the reliability > will not be as great as I wished. > > The main question is now, I believe, whether we want to install > compilation-dependent packages from pypi or rpm. > > _______________________________________________ > qa-devel mailing list -- qa-devel@lists.fedoraproject.org > To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org > >
_______________________________________________ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
