Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-08-03 Thread Alessandro Pilotti
Based on an intial run of the Hyper-V Nova tests with pymox 
(https://github.com/emonty/pymox), only 2 of the tests required some minor 
adjustements while the rest was running perfectly fine by just replacing the 
mox import line.

If we plan to support pymox in Havana, I'd be happy to send a patch for review 
with those fixes.


Alessandro




On Jul 27, 2013, at 02:12 , Joe Gordon 
joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote:


On Jul 26, 2013 5:53 AM, Russell Bryant 
rbry...@redhat.commailto:rbry...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 07/26/2013 05:35 AM, Roman Bogorodskiy wrote:
  Alex Meade wrote:
 
  +1 to everything Russell just said and of course Blueprints for
  this. One for #3 (changing from mox - Mock) would be good so
  that anyone who is bored or finds this urgent can collaborate.
  Also, we need to make sure reviewers are aware (Hopefully they
  are reading this).
 
  -Alex
 
  I have created a blueprint for Nova:
 
  https://blueprints.launchpad.net/nova/+spec/mox-to-mock-conversion
 
  Our team has some spare cycles, so we can work on that.

 Is this really worth it?  The original post identified pymox as
 compatible with mox and Python 3 compatible.  If that's the case,
 making a specific effort to convert everything doesn't seem very
 valuable.  The downsides are risk of changing test behavior and
 unnecessary burden on the review queue.


++

 If a test needs to be changed anyway, then that seems like an
 opportunistic time to go ahead and rewrite it.

 If you have spare cycles, I can probably help find something more
 valuable to work on.  Feel free to come talk to me.  I'd choose most
 of the open bugs over this, for example.  There are hundreds of them
 to choose from.  :-)

 - --
 Russell Bryant
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.13 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iEYEARECAAYFAlHycHkACgkQFg9ft4s9SAYyTQCfY9lKmr6CHNEPb1q0suRBGU/M
 FA0AnR5fJBBG8AsOTX1aIoT845ru3hvH
 =Bpbo
 -END PGP SIGNATURE-

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-26 Thread Russell Bryant
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/26/2013 05:35 AM, Roman Bogorodskiy wrote:
 Alex Meade wrote:
 
 +1 to everything Russell just said and of course Blueprints for
 this. One for #3 (changing from mox - Mock) would be good so
 that anyone who is bored or finds this urgent can collaborate.
 Also, we need to make sure reviewers are aware (Hopefully they
 are reading this).
 
 -Alex
 
 I have created a blueprint for Nova:
 
 https://blueprints.launchpad.net/nova/+spec/mox-to-mock-conversion
 
 Our team has some spare cycles, so we can work on that.

Is this really worth it?  The original post identified pymox as
compatible with mox and Python 3 compatible.  If that's the case,
making a specific effort to convert everything doesn't seem very
valuable.  The downsides are risk of changing test behavior and
unnecessary burden on the review queue.

If a test needs to be changed anyway, then that seems like an
opportunistic time to go ahead and rewrite it.

If you have spare cycles, I can probably help find something more
valuable to work on.  Feel free to come talk to me.  I'd choose most
of the open bugs over this, for example.  There are hundreds of them
to choose from.  :-)

- -- 
Russell Bryant
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHycHkACgkQFg9ft4s9SAYyTQCfY9lKmr6CHNEPb1q0suRBGU/M
FA0AnR5fJBBG8AsOTX1aIoT845ru3hvH
=Bpbo
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-26 Thread Joe Gordon
On Jul 26, 2013 5:53 AM, Russell Bryant rbry...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 07/26/2013 05:35 AM, Roman Bogorodskiy wrote:
  Alex Meade wrote:
 
  +1 to everything Russell just said and of course Blueprints for
  this. One for #3 (changing from mox - Mock) would be good so
  that anyone who is bored or finds this urgent can collaborate.
  Also, we need to make sure reviewers are aware (Hopefully they
  are reading this).
 
  -Alex
 
  I have created a blueprint for Nova:
 
  https://blueprints.launchpad.net/nova/+spec/mox-to-mock-conversion
 
  Our team has some spare cycles, so we can work on that.

 Is this really worth it?  The original post identified pymox as
 compatible with mox and Python 3 compatible.  If that's the case,
 making a specific effort to convert everything doesn't seem very
 valuable.  The downsides are risk of changing test behavior and
 unnecessary burden on the review queue.


++

 If a test needs to be changed anyway, then that seems like an
 opportunistic time to go ahead and rewrite it.

 If you have spare cycles, I can probably help find something more
 valuable to work on.  Feel free to come talk to me.  I'd choose most
 of the open bugs over this, for example.  There are hundreds of them
 to choose from.  :-)

 - --
 Russell Bryant
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.13 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iEYEARECAAYFAlHycHkACgkQFg9ft4s9SAYyTQCfY9lKmr6CHNEPb1q0suRBGU/M
 FA0AnR5fJBBG8AsOTX1aIoT845ru3hvH
 =Bpbo
 -END PGP SIGNATURE-

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-25 Thread Mark McClain

On Jul 25, 2013, at 4:01 AM, Julien Danjou jul...@danjou.info wrote:

 On Wed, Jul 24 2013, Russell Bryant wrote:
 
 A practical approach would probably be:
 
 1) Prefer mock for new tests.
 
 2) Use suggestion #2 above to mitigate the Python 3 concern.
 
 3) Convert tests to mock over time, opportunistically, as tests are
 being updated anyway.  (Or if someone *really* wants to take this on as
 a project ...)
 
 Agreed. I will -1 every new patch coming with mox inside. :-)
 
 And I'll probably do some conversion for Oslo anyway.

The Neutron project has been enforcing this approach for about a year now.  
We're down to 8 files that still rely on Mox.

mark



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-25 Thread Julien Danjou
On Thu, Jul 25 2013, Mark McClain wrote:

 The Neutron project has been enforcing this approach for about a year now.
 We're down to 8 files that still rely on Mox.

Awesome, we'll have to bring Python 3 badges at the next summit for
Neutron devs. ;)

-- 
Julien Danjou
/* Free Software hacker * freelance consultant
   http://julien.danjou.info */


signature.asc
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Chuck Short
Hi,


The use of mox (https://pypi.python.org/pypi/mox/0.5.3) across the test
suites in the Openstack project is quite extensive. This is probably due to
the fact that it is the most familiar mocking object framework for most
python developers.

However there is big drawback with using mox across all of the OpenStack
projects is that it is not python3 compatible. This makes python3
compliance problematic because we want the test suites to be compatible as
well.

While thinking about this problem for a while now, while helping porting
OpenStack over to python3 there is a couple of options that as a project
can do as a whole:

1. Change mox usage to more python3 friendly such as mock. (
https://pypi.python.org/pypi/mock/1.0.1). However this will cause alot of
code churn in the projects as we move away from mox to mock.

2. Use the python3 fork called pymox (https://github.com/emonty/pymox).
This project has reasonable compatibility with mox and is python3
compatible. Using this option causes less code churn. IMHO this would be
the better option.

I would like to hear peoples opinion on this.

Thanks
chuck
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Alex Gaynor
I think moving towards mock is a better long term strategy:

a) I don't you're correct that it's the most familiar for most python
developers. By PyPi installs (A TERRIBLE METRIC, but it's all we have).
Mock has 24k in the last week, mox has 3.5k
b) mock is a part of the standard library starting with python 3.3, this
will lead to even more adoption.

Alex


On Wed, Jul 24, 2013 at 11:12 AM, Chuck Short chuck.sh...@canonical.comwrote:

 Hi,


 The use of mox (https://pypi.python.org/pypi/mox/0.5.3) across the test
 suites in the Openstack project is quite extensive. This is probably due to
 the fact that it is the most familiar mocking object framework for most
 python developers.

 However there is big drawback with using mox across all of the OpenStack
 projects is that it is not python3 compatible. This makes python3
 compliance problematic because we want the test suites to be compatible as
 well.

 While thinking about this problem for a while now, while helping porting
 OpenStack over to python3 there is a couple of options that as a project
 can do as a whole:

 1. Change mox usage to more python3 friendly such as mock. (
 https://pypi.python.org/pypi/mock/1.0.1). However this will cause alot of
 code churn in the projects as we move away from mox to mock.

 2. Use the python3 fork called pymox (https://github.com/emonty/pymox).
 This project has reasonable compatibility with mox and is python3
 compatible. Using this option causes less code churn. IMHO this would be
 the better option.

 I would like to hear peoples opinion on this.

 Thanks
 chuck

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
I disapprove of what you say, but I will defend to the death your right to
say it. -- Evelyn Beatrice Hall (summarizing Voltaire)
The people's good is the highest law. -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Jay Pipes

On 07/24/2013 02:19 PM, Alex Gaynor wrote:

I think moving towards mock is a better long term strategy:

a) I don't you're correct that it's the most familiar for most python
developers. By PyPi installs (A TERRIBLE METRIC, but it's all we have).
Mock has 24k in the last week, mox has 3.5k
b) mock is a part of the standard library starting with python 3.3, this
will lead to even more adoption.


++. I personally prefer mock over mox.

-jay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Kevin L. Mitchell
On Wed, 2013-07-24 at 14:12 -0400, Chuck Short wrote:
 1. Change mox usage to more python3 friendly such as mock.
 (https://pypi.python.org/pypi/mock/1.0.1). However this will cause
 alot of code churn in the projects as we move away from mox to mock.
 
 
 2. Use the python3 fork called pymox
 (https://github.com/emonty/pymox). This project has reasonable
 compatibility with mox and is python3 compatible. Using this option
 causes less code churn. IMHO this would be the better option.

My personal preference is that we move to mock; I think it is a better
methodology, and I like its features.
-- 
Kevin L. Mitchell kevin.mitch...@rackspace.com


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Alex Meade
+1 I prefer mock over mox as well. It's more readable and intuitive. I've had a 
number of bad mox experiences lately so I'm a tad biased.

-Alex

-Original Message-
From: Jay Pipes jaypi...@gmail.com
Sent: Wednesday, July 24, 2013 2:24pm
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Usage of mox through out the Openstack project.

On 07/24/2013 02:19 PM, Alex Gaynor wrote:
 I think moving towards mock is a better long term strategy:

 a) I don't you're correct that it's the most familiar for most python
 developers. By PyPi installs (A TERRIBLE METRIC, but it's all we have).
 Mock has 24k in the last week, mox has 3.5k
 b) mock is a part of the standard library starting with python 3.3, this
 will lead to even more adoption.

++. I personally prefer mock over mox.

-jay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Brian Curtin
On Jul 24, 2013, at 1:12 PM, Chuck Short 
chuck.sh...@canonical.commailto:chuck.sh...@canonical.com
 wrote:

Hi,


The use of mox (https://pypi.python.org/pypi/mox/0.5.3) across the test suites 
in the Openstack project is quite extensive. This is probably due to the fact 
that it is the most familiar mocking object framework for most python 
developers.

However there is big drawback with using mox across all of the OpenStack 
projects is that it is not python3 compatible. This makes python3 compliance 
problematic because we want the test suites to be compatible as well.

While thinking about this problem for a while now, while helping porting 
OpenStack over to python3 there is a couple of options that as a project can do 
as a whole:

1. Change mox usage to more python3 friendly such as mock. 
(https://pypi.python.org/pypi/mock/1.0.1). However this will cause alot of code 
churn in the projects as we move away from mox to mock.

2. Use the python3 fork called pymox (https://github.com/emonty/pymox). This 
project has reasonable compatibility with mox and is python3 compatible. Using 
this option causes less code churn. IMHO this would be the better option.

I would like to hear peoples opinion on this.

Moving towards the standard library's unittest.mock for 3 and the external 
package for 2 is what I've done in the past, but I moved away from mocker and 
another one I forget, not mox.

Are there usages of mox that aren't served by mock? Code churn sucks, but if 
something has to change, I think there's value in moving toward the standard 
facilities if they'll do the job.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Russell Bryant
On 07/24/2013 02:32 PM, Kevin L. Mitchell wrote:
 On Wed, 2013-07-24 at 14:12 -0400, Chuck Short wrote:
 1. Change mox usage to more python3 friendly such as mock.
 (https://pypi.python.org/pypi/mock/1.0.1). However this will cause
 alot of code churn in the projects as we move away from mox to mock.


 2. Use the python3 fork called pymox
 (https://github.com/emonty/pymox). This project has reasonable
 compatibility with mox and is python3 compatible. Using this option
 causes less code churn. IMHO this would be the better option.
 
 My personal preference is that we move to mock; I think it is a better
 methodology, and I like its features.
 

That's fine with me if everyone feels that way.  I'm afraid it's not a
quick move because of how much we're using mox.  A practical approach
would probably be:

1) Prefer mock for new tests.

2) Use suggestion #2 above to mitigate the Python 3 concern.

3) Convert tests to mock over time, opportunistically, as tests are
being updated anyway.  (Or if someone *really* wants to take this on as
a project ...)

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Alex Meade
+1 to everything Russell just said and of course Blueprints for this. One for 
#3 (changing from mox - Mock) would be good so that anyone who is bored or 
finds this urgent can collaborate. Also, we need to make sure reviewers are 
aware (Hopefully they are reading this).

-Alex

-Original Message-
From: Russell Bryant rbry...@redhat.com
Sent: Wednesday, July 24, 2013 2:45pm
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Usage of mox through out the Openstack project.

On 07/24/2013 02:32 PM, Kevin L. Mitchell wrote:
 On Wed, 2013-07-24 at 14:12 -0400, Chuck Short wrote:
 1. Change mox usage to more python3 friendly such as mock.
 (https://pypi.python.org/pypi/mock/1.0.1). However this will cause
 alot of code churn in the projects as we move away from mox to mock.


 2. Use the python3 fork called pymox
 (https://github.com/emonty/pymox). This project has reasonable
 compatibility with mox and is python3 compatible. Using this option
 causes less code churn. IMHO this would be the better option.
 
 My personal preference is that we move to mock; I think it is a better
 methodology, and I like its features.
 

That's fine with me if everyone feels that way.  I'm afraid it's not a
quick move because of how much we're using mox.  A practical approach
would probably be:

1) Prefer mock for new tests.

2) Use suggestion #2 above to mitigate the Python 3 concern.

3) Convert tests to mock over time, opportunistically, as tests are
being updated anyway.  (Or if someone *really* wants to take this on as
a project ...)

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev