[chirp_devel] Using TOX to test on MS Windows
Hello,
I initially used MS Windows to develop some changes to CHIRP. I am having a problem with TOX. It appears that it can not find the chirp modules and the version numbers. I tried building and testing under Linux and things worked fine. I noticed the zip file is named for the version under Linux and unknown with zeros under windows
Is CHIRP only meant to be developed using Linux or do I have a setup problem?
73 Eric
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Sun, Dec 3, 2017 at 10:31 AM, Eric A. Cottrell via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
Hello,
I initially used MS Windows to develop some changes to CHIRP. I am having a problem with TOX. It appears that it can not find the chirp modules and the version numbers. I tried building and testing under Linux and things worked fine. I noticed the zip file is named for the version under Linux and unknown with zeros under windows
Is CHIRP only meant to be developed using Linux or do I have a setup problem?
73 Eric
Hi Eric,
It must be something to do with your setup. I almost exclusively do my CHIRP development on a Windows 7 Home 64-bit desktop.
Jim KC9HI
I initially used MS Windows to develop some changes to CHIRP. I am having a problem with TOX. It appears that it can not find the chirp modules and the version numbers. I tried building and testing under Linux and things worked fine. I noticed the zip file is named for the version under Linux and unknown with zeros under windows
Is CHIRP only meant to be developed using Linux or do I have a setup problem?
73 Eric
Hi Eric,
It must be something to do with your setup. I almost exclusively do my CHIRP development on a Windows 7 Home 64-bit desktop.
Jim, I should have asked before I switched the tree to using tox, but is that working for you under windows? It should, but I didn’t test it. Maybe you’re still running with run_tests? That should be fine for now, but I did a bunch of work recently to make it work under tox properly which is a lot better for the build system and for repeatability in general.
Eric, can you paste some output so I can see what is happening?
Thanks!
—Dan
Jim, I should have asked before I switched the tree to using tox, but is that working for you under windows? It should, but I didn’t test it. Maybe you’re still running with run_tests? That should be fine for now, but I did a bunch of work recently to make it work under tox properly which is a lot better for the build system and for repeatability in general.
Yeah. I think I posted a comment after the change that "run_all_test.bat" is broken. I had to edit the batch file to get it to run.
So what is this TOX thing?
Jim
Yeah. I think I posted a comment after the change that "run_all_test.bat" is broken. I had to edit the batch file to get it to run.
Ah, okay, wanna send a patch for that in the meantime at least?
So what is this TOX thing?
The tox tool is a thing that builds virtual environments for the purposes of running tests. It insulates the running tests from your actual system to a high degree, which means that tests should be a little easier to run in more places. It installs the packages that we need and properly “installs” chirp to run the tests. It’s a lot better for the build system, which means it should break less and require less maintenance from me.
Now, if you have tox installed, all you should need to do to run the tests is type “tox”. It’ll build the venvs for driver and style checks the first time and then run the tests. I also have made the driver tests fit into the standard python testing infrastructure so we can use the regular test runners. In the future, that will let me run them in parallel more easily, which will make it much quicker to get a test result.
On windows, try running this to install too:
python -mpip install tox
Let’s see what Eric reports about what isn’t working to see if it’s something easy. Luckily, I was able to do all of the above without disturbing the regular way of running tests, so you can continue to do that until we sort it out.
—Dan
On 12/3/2017 12:29 PM, Dan Smith via chirp_devel wrote:
Yeah. I think I posted a comment after the change that "run_all_test.bat" is broken. I had to edit the batch file to get it to run.
Ah, okay, wanna send a patch for that in the meantime at least?
So what is this TOX thing?
The tox tool is a thing that builds virtual environments for the purposes of running tests. It insulates the running tests from your actual system to a high degree, which means that tests should be a little easier to run in more places. It installs the packages that we need and properly “installs” chirp to run the tests. It’s a lot better for the build system, which means it should break less and require less maintenance from me.
Now, if you have tox installed, all you should need to do to run the tests is type “tox”. It’ll build the venvs for driver and style checks the first time and then run the tests. I also have made the driver tests fit into the standard python testing infrastructure so we can use the regular test runners. In the future, that will let me run them in parallel more easily, which will make it much quicker to get a test result.
On windows, try running this to install too:
python -mpip install tox
Let’s see what Eric reports about what isn’t working to see if it’s something easy. Luckily, I was able to do all of the above without disturbing the regular way of running tests, so you can continue to do that until we sort it out.
—Dan _______________________________________________
Hello,
I was using tox. I just tried run_all_test.bat which partly works. The run_all_test.bat problem is the "python tests\run_tests" line in the batch file will run the run_tests shell script instead of the run_tests.py file. If I enter python tests\run_tests.py on the command line it works.
The problem with tox seems to be the zip file under .tox/dist is not named with the right version number and is missing most of the needed files. I have included the output/logs of running tox.
73 Eric
On Sun, Dec 3, 2017 at 3:32 PM Eric A. Cottrell via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
On 12/3/2017 12:29 PM, Dan Smith via chirp_devel wrote:
Yeah. I think I posted a comment after the change that "run_all_test.bat" is broken. I had to edit the batch file to get it to run.
Ah, okay, wanna send a patch for that in the meantime at least?
So what is this TOX thing?
The tox tool is a thing that builds virtual environments for the purposes of running tests. It insulates the running tests from your actual system to a high degree, which means that tests should be a little easier to run in more places. It installs the packages that we need and properly “installs” chirp to run the tests. It’s a lot better for the build system, which means it should break less and require less maintenance from me.
Now, if you have tox installed, all you should need to do to run the tests is type “tox”. It’ll build the venvs for driver and style checks the first time and then run the tests. I also have made the driver tests fit into the standard python testing infrastructure so we can use the regular test runners. In the future, that will let me run them in parallel more easily, which will make it much quicker to get a test result.
On windows, try running this to install too:
python -mpip install tox
Let’s see what Eric reports about what isn’t working to see if it’s something easy. Luckily, I was able to do all of the above without disturbing the regular way of running tests, so you can continue to do that until we sort it out.
—Dan _______________________________________________
Hello,
I was using tox. I just tried run_all_test.bat which partly works. The run_all_test.bat problem is the "python tests\run_tests" line in the batch file will run the run_tests shell script instead of the run_tests.py file. If I enter python tests\run_tests.py on the command line it works.
The problem with tox seems to be the zip file under .tox/dist is not named with the right version number and is missing most of the needed files. I have included the output/logs of running tox.
73 Eric
Dan,
Has this been looked into yet? I'm in to process of replacing my very old CHIRP development computer. I've gone through the DevelopersWin32Environment setup (writing down all additional steps that are needed) and the only thing that doesn't work is the running of the the tests using tox. I basically get the same error(s) that Eric is getting according to the logs he provided.
Thanks, Jim KC9HI
Has this been looked into yet? I'm in to process of replacing my very old CHIRP development computer. I've gone through the DevelopersWin32Environment setup (writing down all additional steps that are needed) and the only thing that doesn't work is the running of the the tests using tox. I basically get the same error(s) that Eric is getting according to the logs he provided.
Not in depth, but I'm pretty sure it's related to how the setup.py doesn't allow sdist to be performed when on win32, but rather short-circuits to py2exe invocation. Tox is going to want the sdist.
We should probably just remove the py2exe bit from the in-tree setup file to make it more uniform, since my build stuff doesn't really even using it at the moment. I haven't done that yet because I need to be careful that I don't disrupt the ability to do the regular builds in some way and need a bit of time to focus on it and I just haven't yet with the holidays.
In your local tree, you can try removing the "if win32 do special stuff" condition and instead make it do what it would do on linux to see if that gets your further.
--Dan
On Thu, Jan 2, 2020 at 5:33 PM Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
Has this been looked into yet? I'm in to process of replacing my very old CHIRP development computer. I've gone through the DevelopersWin32Environment setup (writing down all additional steps that are needed) and the only thing that doesn't work is the running of the the tests using tox. I basically get the same error(s) that Eric is getting according to the logs he provided.
Not in depth, but I'm pretty sure it's related to how the setup.py doesn't allow sdist to be performed when on win32, but rather short-circuits to py2exe invocation. Tox is going to want the sdist.
We should probably just remove the py2exe bit from the in-tree setup file to make it more uniform, since my build stuff doesn't really even using it at the moment. I haven't done that yet because I need to be careful that I don't disrupt the ability to do the regular builds in some way and need a bit of time to focus on it and I just haven't yet with the holidays.
In your local tree, you can try removing the "if win32 do special stuff" condition and instead make it do what it would do on linux to see if that gets your further.
--Dan
smb://tower/data/tox_output.txt
Dan,
What I did was to remove the following lines from the setup.py in the chirp.hg file.
elif sys.platform == "win32": win32_build()
I think that is what you wanted.
I executed tox and piped the output it to a file (attached). This definitely got further. It looks like there were some permissions errors during the tests. I don't know if those are normal errors for pep8 or not.
Jim
What I did was to remove the following lines from the setup.py in the chirp.hg file.
elif sys.platform == "win32": win32_build()
I think that is what you wanted.
Yep.
I executed tox and piped the output it to a file (attached). This definitely got further. It looks like there were some permissions errors during the tests. I don't know if those are normal errors for pep8 or not.
The unit test permissions failures are a little weird since it's just trying to write to files returned to it from the mktemp function. The style issues look like they may be related to windows-style line endings, although I'm not sure why it's complaining about only a few files amongst many.
Anyway, definitely much farther. I'd have to spin up a windows dev environment to debug them myself.
Today's win32 build should have ignored the in-tree setup.py file for the exe generation part. If someone can confirm that it looks okay on windows, I can remove the "if win32" bit in the main setup.py file so that it works like your test above for developers.
--Dan
participants (3)
-
Dan Smith
-
Eric A. Cottrell
-
Jim Unroe