Re: [openstack-dev] Navigating the ever changing OpenStack codebase
Excerpts from Kevin L. Mitchell's message of 2015-04-27 17:38:25 -0500: On Mon, 2015-04-27 at 21:42 +, Jeremy Stanley wrote: I consider it an unfortunate oversight that those files weren't deleted a very, very long time ago. Unfortunately, there's one problem with that: you can't tell tox to use a virtualenv that you've built. We need this capability at present, so we have to run tests using run_tests.sh instead of tox :( I have an issue open on tox to address this need, but haven't seen any movement on that; so until then, I have to oppose the removal of run_tests.sh… despite how much *I'd* like to see it bite the dust! I had a similar requirement at one point and was able to use tox --notests to create the virtualenv, then modify it to add the tools I wanted, then run tox again to run the tests. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
On 04/27/2015 06:38 PM, Kevin L. Mitchell wrote: On Mon, 2015-04-27 at 21:42 +, Jeremy Stanley wrote: I consider it an unfortunate oversight that those files weren't deleted a very, very long time ago. Unfortunately, there's one problem with that: you can't tell tox to use a virtualenv that you've built. We need this capability at present, so we have to run tests using run_tests.sh instead of tox :( I have an issue open on tox to address this need, but haven't seen any movement on that; so until then, I have to oppose the removal of run_tests.sh… despite how much *I'd* like to see it bite the dust! Honestly, I see no problem with some helper bash scripts that simplify life for new contributors. The bash scripts do wonders for developers new to OpenStack or Python coding by having a pretty easy and readable way of determining what CLI commands are used to execute tests. Hell, devstack [1] itself was written originally in the way it was to well-document the deployment process for OpenStack. Many packagers and configuration management script authors have looked at devstack's Bash scripts for inspiration and instruction in this way. The point Ronald was making that nobody seems to have addressed is the very valid observation that as a new contributor, it can be very confusing to go from one project to another and see different ways of running tests. Some projects have run_tests.sh and still actively promote it in the devref docs. Others don't While Ronald seems to have been the victim of unfortunate timing (he started toying around with python-openstackclient and within a week, they removed the script he was using to run tests), that doesn't make his point about our inconsistency moot. Best, -jay [1] http://docs.openstack.org/developer/devstack/stack.sh.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
On Tue, Apr 28, 2015 at 2:56 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-04-28 16:08:03 -0400 (-0400), Jay Pipes wrote: Honestly, I see no problem with some helper bash scripts that simplify life for new contributors. [...] [...] I remember it happening regularly before we started begging people to run tox and instead remove those scripts where possible. The arguments for pushing people to tox make good sense, but it seems like there will still be cases where run_tests.sh continues to exist for whatever reason. For the sake of the new contributors, what about including a warning when running run_tests.sh reminding them to use tox if possible? For the cases where the script can't be removed entirely, it will at least help eager new folks (who are very likely to pull a repo and look for a helpfully named script like that - I'm certainly guilty of rushing ahead sometimes, running scripts while reading docs...) -Christopher __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
On Mon, 2015-04-27 at 15:54 -0700, Clint Byrum wrote: Excerpts from Kevin L. Mitchell's message of 2015-04-27 15:38:25 -0700: On Mon, 2015-04-27 at 21:42 +, Jeremy Stanley wrote: I consider it an unfortunate oversight that those files weren't deleted a very, very long time ago. Unfortunately, there's one problem with that: you can't tell tox to use a virtualenv that you've built. We need this capability at present, so we have to run tests using run_tests.sh instead of tox :( I have an issue open on tox to address this need, but haven't seen any movement on that; so until then, I have to oppose the removal of run_tests.sh… despite how much *I'd* like to see it bite the dust! Err.. you can just run the commands in tox.ini in the venv of your choice. You don't need run_tests.sh for that. No dice. I don't want to have to parse the tox.ini directly. We're talking about automated tests here, by the way. -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
Thanks again for the clarification. Your initial --notests was an option I was unaware of and I didn't take the time to try variations. I was familiar with invoking test names by regex I just thought it was more a convention. Regards Ronald On Tue, Apr 28, 2015 at 2:48 PM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Ronald Bradford's message of 2015-04-28 14:24:37 -0400: Thanks Doug. For others following this thread. The following creates and activates the tox virtual environment. # Note: its --spacenotests not --notests Sorry, that was a typo on my part. The option name is actually '--notest' (no s at the end). That causes tox to do everything it would normally do, except for the step where it runs the command list for the named environment. $ tox -epy27 -- notests This becomes: $ tox -e py27 --notest Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
On Tue, 2015-04-28 at 16:08 -0400, Jay Pipes wrote: Honestly, I see no problem with some helper bash scripts that simplify life for new contributors. The bash scripts do wonders for developers new to OpenStack or Python coding by having a pretty easy and readable way of determining what CLI commands are used to execute tests. Hell, devstack [1] itself was written originally in the way it was to well-document the deployment process for OpenStack. Many packagers and configuration management script authors have looked at devstack's Bash scripts for inspiration and instruction in this way. The point Ronald was making that nobody seems to have addressed is the very valid observation that as a new contributor, it can be very confusing to go from one project to another and see different ways of running tests. Some projects have run_tests.sh and still actively promote it in the devref docs. Others don't While Ronald seems to have been the victim of unfortunate timing (he started toying around with python-openstackclient and within a week, they removed the script he was using to run tests), that doesn't make his point about our inconsistency moot. Completely agreed, actually; I was only responding to the comment suggesting the complete removal of run_tests.sh. I personally think we should promote only tox in the various doc files, and reference run_tests.sh only as a legacy thing we can't fully get rid of quite yet. (Incidentally, for my testing purposes, I don't care where it is, as long as it's somewhere; so we could also move it to, say, tools. I don't even care what it outputs, as long as it gives a reasonable return value; so we could have it print out a scary-looking warning about it being legacy… :) -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
On 2015-04-28 16:08:03 -0400 (-0400), Jay Pipes wrote: Honestly, I see no problem with some helper bash scripts that simplify life for new contributors. [...] Well, the main downside to them is that rather than serving as documentation of how to run the tests, they serve as a temptation to developers using them to start adding workarounds for various things and can end up in a situation where what we're gating on acts nothing like what the developers who run that script are actually getting. And then that leads to even more confusion because they don't realize that their problem is being hidden by something hacked into run_tests.sh so they think the automated CI is broken instead. I remember it happening regularly before we started begging people to run tox and instead remove those scripts where possible. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
Excerpts from Kevin L. Mitchell's message of 2015-04-28 08:15:51 -0700:
On Mon, 2015-04-27 at 15:54 -0700, Clint Byrum wrote:
Excerpts from Kevin L. Mitchell's message of 2015-04-27 15:38:25 -0700:
On Mon, 2015-04-27 at 21:42 +, Jeremy Stanley wrote:
I consider it an unfortunate oversight that those files weren't
deleted a very, very long time ago.
Unfortunately, there's one problem with that: you can't tell tox to use
a virtualenv that you've built. We need this capability at present, so
we have to run tests using run_tests.sh instead of tox :( I have an
issue open on tox to address this need, but haven't seen any movement on
that; so until then, I have to oppose the removal of run_tests.sh…
despite how much *I'd* like to see it bite the dust!
Err.. you can just run the commands in tox.ini in the venv of your
choice. You don't need run_tests.sh for that.
No dice. I don't want to have to parse the tox.ini directly. We're
talking about automated tests here, by the way.
Why not? It's an ini file, with a stable interface.
Python 3.4.0 (default, Apr 11 2014, 13:05:11)
[GCC 4.8.2] on linux
Type help, copyright, credits or license for more information.
import configparser
x = configparser.ConfigParser()
x.read('tox.ini')
['tox.ini']
x.get('testenv', 'commands')
\npython setup.py testr --slowest --testr-args='{posargs}'
I'm sure you've thought more about this than me, so I apologize for
sounding dense. However, I'm struggling to see where having to maintain
two test harnesses is less complicated than the code above.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
Thanks Doug. For others following this thread. The following creates and activates the tox virtual environment. # Note: its --spacenotests not --notests $ tox -epy27 -- notests $ source .tox/py27/bin/activate (py27)$ openstack help -- http://ronaldbradford.com/blog/running-openstack-tests-with-tox-2015-04-28/ 01010010 0110 01101110 0111 01101100 01100100 0010 0110 01110010 0111 01100100 01100110 0110 01110010 01100100 *Ronald Bradford* MySQL Expert specializing in Performance Tuning, Scalability and High Availability Lead Author - Effective MySQL: Replication Techniques In Depth http://effectivemysql.com/book/replication-techniques/ - 2012, Author - Effective MySQL: Backup and Recovery http://effectivemysql.com/book/replication-techniques/ - 2012, Author - Effective MySQL: Optimizing SQL Statements http://effectivemysql.com/book/optimizing-sql-statements/ - 2011, Co-author - Expert PHP and MySQL http://expertphpandmysql.com/ - 2010 All-time top MySQL Blogger - 2011 http://mysqlpreacher.com/wordpress/2011/01/mysql-community-blogging-%E2%80%93-planetmysql-part-2/ , Oracle ACE Director - 2010 http://apex.oracle.com/pls/otn/f?p=19297:4:134763154226248::NO:4:P4_ID:1820 , MySQL Community Member of the Year - 2009 http://www.mysql.com/why-mysql/awards/community-2009.html Download Contact Details: http://effectivemysql.com/contact-details/ Web Site: http://ronaldbradford.com Linked In: http://www.linkedin.com/in/ronaldbradford Twitter: @RonaldBradford http://twitter.com/ronaldbradford, @MySQLExpert http://twitter.com/MySQLExpert Skype: RonaldBradford GTalk: Ronald.Bradford On Tue, Apr 28, 2015 at 10:44 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Kevin L. Mitchell's message of 2015-04-27 17:38:25 -0500: On Mon, 2015-04-27 at 21:42 +, Jeremy Stanley wrote: I consider it an unfortunate oversight that those files weren't deleted a very, very long time ago. Unfortunately, there's one problem with that: you can't tell tox to use a virtualenv that you've built. We need this capability at present, so we have to run tests using run_tests.sh instead of tox :( I have an issue open on tox to address this need, but haven't seen any movement on that; so until then, I have to oppose the removal of run_tests.sh… despite how much *I'd* like to see it bite the dust! I had a similar requirement at one point and was able to use tox --notests to create the virtualenv, then modify it to add the tools I wanted, then run tox again to run the tests. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
Excerpts from Ronald Bradford's message of 2015-04-28 14:24:37 -0400: Thanks Doug. For others following this thread. The following creates and activates the tox virtual environment. # Note: its --spacenotests not --notests Sorry, that was a typo on my part. The option name is actually '--notest' (no s at the end). That causes tox to do everything it would normally do, except for the step where it runs the command list for the named environment. $ tox -epy27 -- notests This becomes: $ tox -e py27 --notest Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
On 29 April 2015 at 06:24, Ronald Bradford m...@ronaldbradford.com wrote: Thanks Doug. For others following this thread. The following creates and activates the tox virtual environment. # Note: its --spacenotests not --notests $ tox -epy27 -- notests $ source .tox/py27/bin/activate (py27)$ openstack help Actually no, its '--notest' - see tox --help. What you've done is run the tests with a filter that didn't match any tests. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
On Tue, 2015-04-28 at 10:40 -0700, Clint Byrum wrote: No dice. I don't want to have to parse the tox.ini directly. We're talking about automated tests here, by the way. Why not? It's an ini file, with a stable interface. Yes, but it's tox's perview. Also, it's not just the command; I may be building my own virtual environment to use, but there are other environment variables typically set up by the test environment (e.g., PYTHONHASHSEED). Also, there could be multiple tests to run, e.g., I might need to run py27 and pep8. With all of that, getting the proper test setup programmatically becomes almost a bastardized reimplementation of tox, and I'd *really* rather not do that. As I say, I'd love to just run tox; I just need it to use my virtualenv, not build another. I'm sure you've thought more about this than me, so I apologize for sounding dense. However, I'm struggling to see where having to maintain two test harnesses is less complicated than the code above. Well, we don't typically make all that many changes to the test harness to begin with, so while it's not exactly the ideal situation, it's not really all that hard to try to maintain both (though admittedly a bit more error prone). Also, run_tests.sh typically doesn't run all the tests that tox is capable of running, and that's fine; as long as it runs basic acceptance-type tests (e.g., unit tests and pep8), I'm happy. I raised this issue before on the list some months ago…IIRC, it was when someone had proposed removing run_tests.sh from nova. I explained why I needed it and pointed to the tox issue I had open. As I recall, that thread included some comments from some other operators that also wanted to use run_tests.sh for basically the same reason we were: acceptance tests on the virtual environment. The result of that thread was to keep run_tests.sh around for now. I can say that, if the issue I reported ever gets addressed, I'll happily drop run_tests.sh like a hot potato. (Well, there's some other minor issue, having to do with odd characters in path names, but I can just find a different way to encode the path name to deal with that problem :) -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
Excerpts from Jeremy Stanley's message of 2015-04-27 21:42:15 +: On 2015-04-27 17:07:56 -0400 (-0400), Ronald Bradford wrote: [...] Specifically, the following two code snippets have become SOP (Standard Operating Procedure) jumping around VMs and projects and I suspect if you are a developer of this project, something you are very familiar with. [...] python tools/install_venv.py source .venv/bin/activate ./run_tests.sh [...] Not in my experience--common wisdom for the ~2.5 years I've been involved has been to use tox. It's how we run these tests in gate jobs, so if a developer is running in a different way they're likely to encounter all sorts of inconsistencies between their local results and what the CI eventually reports for a proposed change. it not longer exists in this project. [...] I consider it an unfortunate oversight that those files weren't deleted a very, very long time ago. Yes, I think that's why they were finally removed. We just hadn't noticed they were still there. For the record, the review that removed run_tests.sh was https://review.openstack.org/#/c/177066/ Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
On 2015-04-27 17:07:56 -0400 (-0400), Ronald Bradford wrote: [...] Specifically, the following two code snippets have become SOP (Standard Operating Procedure) jumping around VMs and projects and I suspect if you are a developer of this project, something you are very familiar with. [...] python tools/install_venv.py source .venv/bin/activate ./run_tests.sh [...] Not in my experience--common wisdom for the ~2.5 years I've been involved has been to use tox. It's how we run these tests in gate jobs, so if a developer is running in a different way they're likely to encounter all sorts of inconsistencies between their local results and what the CI eventually reports for a proposed change. it not longer exists in this project. [...] I consider it an unfortunate oversight that those files weren't deleted a very, very long time ago. So I've solved how to run tests the new way, took longer to write this email. Still none the wiser how to run my code in a developer virtual environment. When you use tox, it creates a virtualenv for each testenv in the envlist from the tox.ini in the repo. You can find these virtualenvs in the .tox directory after it runs, and can activate and update them as needed. The documentation for tox is also quite comprehensive (and linked from the wiki article you were quoting): http://testrun.org/tox/ Or, you can activate the env and run testr manually (for projects using it, which is most of them now) as mentioned in the Writing Tests for testr wiki article for testr you linked in your message: https://wiki.openstack.org/wiki/Testr#Writing_Tests_for_testr -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Navigating the ever changing OpenStack codebase
Hi All, I have recently become involved in OpenStack development. After installing a few devstacks (and buying some H/W for my own physical cloud) I settled into learning, reviewing and debugging the Python OpenStack Client (seemed an easy access point). I even published a blog post just 7 days ago on my experiences of Python Virtual Environments (something I was not yet familiar with. Python being about 10+ on my list of known languages) at http://ronaldbradford.com/blog/inconsistent-messaging-for-openstackclient-2015-04-20/. Since then I've been debugging the code and preparing to write some test cases for what I consider is a small bug, and understand how to work on making a contribution to that. Specifically, the following two code snippets have become SOP (Standard Operating Procedure) jumping around VMs and projects and I suspect if you are a developer of this project, something you are very familiar with. git clone git://git.openstack.org/openstack/python-openstackclient cd python-openstackclient python tools/install_venv.py source .venv/bin/activate ./run_tests.sh Today I went to pickup where I left off last week and I find with an updated code base and run_tests.sh didn't work. Infact it not longer exists in this project. See https://review.openstack.org/#/c/177066/ I also found that tools/install_venv.py also gone, see https://review.openstack.org/#/c/177086/ So, I'm back to knowing almost nil about running tests and debugging my own code in under a week. While I appreciate the OpenStack codebase is a growing and evolving project and I'm still a relative newbie, I'm a little lost in the traceability and the audibility of a structural change (in other words, how you run unit tests and setup virtual environments). I suspect I'm missing something in the information flow. I'm on a few mailing lists, in a few IRC rooms, but I found this out by looking at commit messages at https://git.openstack.org/cgit/openstack/python-openstackclient/. I am unfamiliar with what is the best place for looking at information to remain informed. run_tests.sh is a great example where there was no deprecation message and there is indeed no backward compatibility. i.e. a run_test.sh that states: Run tox instead. This would at least not catch newbies off guard as much when reading various documentation. I also am lead to believe each project is self-governed (which is great as it doesn't hobble projects by decision making) but that also leads to different approaches on different projects. You don't want each project to become siloed and difficult to navigate between them. There was a choice many years ago to standardize on Python. There are choices on coding standards. Does this exist for testing too? As somebody new to OpenStack code base and willing to contribute, even the How to Contribute (https://wiki.openstack.org/wiki/How_To_Contribute ) while helpful is a lot to tackle. This next step to getting to know the code, and I've not found a great source for this. I found it better to just get stuck in downloading, reading and running it. I looked back and came across this link I did read some time ago -- http://docs.openstack.org/developer/cinder/devref/development.environment.html Anybody able to provide recommendations for the new developer in the OS space I would greatly appreciate it. Having written this email draft I have delved into reading more about testing. I started with the projects HACKING.rst which lead to https://wiki.openstack.org/wiki/Testr and now https://wiki.openstack.org/wiki/Testing. I should point out the last link specifically states. run_tests.sh There is an older convention, as follows. Most projects have a shell script, named run_tests.sh, that runs the unit tests of that project. ... So I've solved how to run tests the new way, took longer to write this email. Still none the wiser how to run my code in a developer virtual environment. Regards Ronald __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
Excerpts from Kevin L. Mitchell's message of 2015-04-27 15:38:25 -0700: On Mon, 2015-04-27 at 21:42 +, Jeremy Stanley wrote: I consider it an unfortunate oversight that those files weren't deleted a very, very long time ago. Unfortunately, there's one problem with that: you can't tell tox to use a virtualenv that you've built. We need this capability at present, so we have to run tests using run_tests.sh instead of tox :( I have an issue open on tox to address this need, but haven't seen any movement on that; so until then, I have to oppose the removal of run_tests.sh… despite how much *I'd* like to see it bite the dust! Err.. you can just run the commands in tox.ini in the venv of your choice. You don't need run_tests.sh for that. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
On Mon, 2015-04-27 at 21:42 +, Jeremy Stanley wrote: I consider it an unfortunate oversight that those files weren't deleted a very, very long time ago. Unfortunately, there's one problem with that: you can't tell tox to use a virtualenv that you've built. We need this capability at present, so we have to run tests using run_tests.sh instead of tox :( I have an issue open on tox to address this need, but haven't seen any movement on that; so until then, I have to oppose the removal of run_tests.sh… despite how much *I'd* like to see it bite the dust! -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Navigating the ever changing OpenStack codebase
On 2015-04-27 17:38:25 -0500 (-0500), Kevin L. Mitchell wrote: Unfortunately, there's one problem with that: you can't tell tox to use a virtualenv that you've built. We need this capability at present, so we have to run tests using run_tests.sh instead of tox :( I have an issue open on tox to address this need, but haven't seen any movement on that; so until then, I have to oppose the removal of run_tests.sh… despite how much *I'd* like to see it bite the dust! Bug report is https://bitbucket.org/hpk42/tox/issue/153 for those following along. I agree that's unfortunate, though a (likely suboptimal) workaround is to have tox create the virtualenv, then do whatever you need to modify it, then don't have tox recreate it on a subsequent run of your tests. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
