Hey All, I know it's been a while since I've been able to make any progress on pyres and I wanted to give some updates on what's going on. First, After talking to some people at pycon, I've decided that I'm going to give more people commit bit to the project. Along with this, i'm also going to move the primary repository over to the pyres org account here: https://github.com/pyres. This should help with fixing bugs and keeping pyres up to date with redis. Second, development path. I've started working on some ideas and docs on what pyres 2 is going to look like. One feature that I'm leaning towards is basing a lot of the plumbing on Ben Bangerts retools project( https://github.com/bbangert/retools). He has some really nice conventions for events/hooks that would make pyres much more extensible. I've also been thinking about splitting resweb out into it's own project, because it's a bit ridiculous to require itty or flask for a server side processing framework. I'd also like to head down a path where we could integrate resweb with other frameworks, say a django admin module, etc. Finally, current tickets/pull requests. With the switch over to the pyres organization, i'm going to close all current requests and tickets on my repository about a month after the move. Anything that I think is very important I will also move over. Please let me know if you have any ideas or thoughts. thanks, Matt
Hi Matt, On Tue, Mar 13, 2012 at 12:14 PM, matt george <mgeorge@gmail.com> wrote: > Second, development path. I've started working on some ideas and docs on > what pyres 2 is going to look like. What's your general philosophy with regards to compatibility with Resque? Is that something that is important to you and other users of pyres? I work in an all-Python shop for now so it's not particularly important to me, but I could see that it might be for others. Does it even work alongside Resque? Joe
Hey Joe, I was actually discussing that with some people at pycon over lunch a few days ago. My question would be, when you say compatibility with resque, in what manner are you talking about. Are you talking about pushing jobs to resque from pyres or the reverse, or are you talking about being able to view resque state via resweb? Originally, when I started pyres i wanted to keep the api as similar to resque as possible. That is still something i'd be interested in looking at, but it's no longer a main concern. Basically, if we can keep the api very similar that's cool, but I don't want to sacrifice functionality in order to do so. Matt -- Matt George mgeorge@gmail.com On Tuesday, March 13, 2012 at 10:26 AM, Joe Shaw wrote: > Hi Matt, > > On Tue, Mar 13, 2012 at 12:14 PM, matt george <mgeorge@gmail.com (mailto:mgeorge@gmail.com)> wrote: > > Second, development path. I've started working on some ideas and docs on > > what pyres 2 is going to look like. > > > > > What's your general philosophy with regards to compatibility with > Resque? Is that something that is important to you and other users of > pyres? I work in an all-Python shop for now so it's not particularly > important to me, but I could see that it might be for others. Does it > even work alongside Resque? > > Joe
Hi Matt, On Tue, Mar 13, 2012 at 1:36 PM, Matt George <mgeorge@gmail.com> wrote: > I was actually discussing that with some people at pycon over lunch a few > days ago. My question would be, when you say compatibility with resque, in > what manner are you talking about. Are you > talking about pushing jobs to resque from pyres or the reverse, or are you > talking about being able to view resque state via resweb? Honestly, I don't know. Pyres uses the same Redis keys as Resque, so there is some implied compatibility, but I've never actually tried running them side-by-side. My recollection of the code is that Pyres probably wouldn't deal well with having a Ruby-encoded job in a queue. The converse is probably also true. Viewing them in Resweb would be nice, although if you can't run them both at the same time I'm not sure what difference it makes. Maybe Pyres should use a different Redis namespace? > Originally, when I started pyres i wanted to keep the api as similar to > resque as possible. That is still something i'd be interested in looking at, > but it's no longer a main concern. Basically, if we > can keep the api very similar that's cool, but I don't want to sacrifice > functionality in order to do so. Ok, that's good to know. Thanks. Joe > > Matt > -- > Matt George > mgeorge@gmail.com > > On Tuesday, March 13, 2012 at 10:26 AM, Joe Shaw wrote: > > Hi Matt, > > On Tue, Mar 13, 2012 at 12:14 PM, matt george <mgeorge@gmail.com> wrote: > > Second, development path. I've started working on some ideas and docs on > what pyres 2 is going to look like. > > > What's your general philosophy with regards to compatibility with > Resque? Is that something that is important to you and other users of > pyres? I work in an all-Python shop for now so it's not particularly > important to me, but I could see that it might be for others. Does it > even work alongside Resque? > > Joe > >
On Thursday, March 15, 2012 at 8:52 AM, Joe Shaw wrote: > Hi Matt, > > On Tue, Mar 13, 2012 at 1:36 PM, Matt George <mgeorge@gmail.com (mailto:mgeorge@gmail.com)> wrote: > > I was actually discussing that with some people at pycon over lunch a few > > days ago. My question would be, when you say compatibility with resque, in > > what manner are you talking about. Are you > > talking about pushing jobs to resque from pyres or the reverse, or are you > > talking about being able to view resque state via resweb? > > > > > Honestly, I don't know. Pyres uses the same Redis keys as Resque, so > there is some implied compatibility, but I've never actually tried > running them side-by-side. My recollection of the code is that Pyres > probably wouldn't deal well with having a Ruby-encoded job in a queue. > The converse is probably also true. > > The name spacing is one of the things I want to address with version 2. One of the ideas that I want to play around with is to have a standard namespace, but to allow overriding that namespace in configuration. This override could allow resweb to view resque data as well as pyres. > Viewing them in Resweb would be nice, although if you can't run them > both at the same time I'm not sure what difference it makes. > > Maybe Pyres should use a different Redis namespace? > > > Originally, when I started pyres i wanted to keep the api as similar to > > resque as possible. That is still something i'd be interested in looking at, > > but it's no longer a main concern. Basically, if we > > can keep the api very similar that's cool, but I don't want to sacrifice > > functionality in order to do so. > > > > > Ok, that's good to know. Thanks. > > Joe > > > > > > Matt > > -- > > Matt George > > mgeorge@gmail.com (mailto:mgeorge@gmail.com) > > > > On Tuesday, March 13, 2012 at 10:26 AM, Joe Shaw wrote: > > > > Hi Matt, > > > > On Tue, Mar 13, 2012 at 12:14 PM, matt george <mgeorge@gmail.com (mailto:mgeorge@gmail.com)> wrote: > > > > Second, development path. I've started working on some ideas and docs on > > what pyres 2 is going to look like. > > > > > > What's your general philosophy with regards to compatibility with > > Resque? Is that something that is important to you and other users of > > pyres? I work in an all-Python shop for now so it's not particularly > > important to me, but I could see that it might be for others. Does it > > even work alongside Resque? > > > > Joe