Fair enough. I've updated my two forks with an extra option in the setup.cfg file that uses a different build directory to solve that problem. I have no issue with using pants or or not (so long as vanilla setuptools works), though I was having issues getting pants to use these forks (via the git support built into setuptools) in an external project, so gave up and just used pip.
On 23 July 2014 17:42, Brian Wickman <[email protected]> wrote: > They can be installed via setuptools -- the repositories have setup.py > files included at the root so that source distributions can be made. > Nothing's been published to pypi yet though, since I don't feel they're > even ready for an 0.1 release. I pantsified the repositories to make it > easier to run tests, but am happy to toxify them instead -- whatever people > are most comfortable with. Re: BUILD vs build, you should be able to > specify an alternate build path for setuptools so that it doesn't conflict > when building distributions. > > > On Wed, Jul 23, 2014 at 12:01 AM, Tom Arnfeld <[email protected]> wrote: > > > R.E Python 3.3; > > > > It doesn't actually require it, but it's importing asyncio directly > > instead of using the standard try/catch around the import and falling > back > > to trollius (the Python2 port). We can probably import via tornado, which > > does this try/catch for us. > > > > Right now both compactor and pesos can't be installed with setuptools due > > to the BUILD files (setuptools tries to create build folders and the name > > conflicts). I'll be fixing this up today by removing pants, at least just > > to get it working... not sure how Brian feels about that yet ;-) > > > > I can ping the mailing list once both compactor and pesos are up and > > running in an easy-to-use way (next few hours). I've been using > > https://github.com/tarnfeld/mesos-python-framework as a test framework > > skeleton, but that's also not easy to set up just yet. > > > > Note: Regardless of the above, you need to have installed our fork of > > tornado for anything to work beyond the first round of messages. > > > > Cheers, > > > > Tom. > > > > On 23 Jul 2014, at 07:42, Vetoshkin Nikita <[email protected]> > > wrote: > > > > > Hi, Tom! > > > I would gladly help you to debug if you could provide some information > > > about your setup. Is it localhost only communication? Any code snippet > to > > > reproduce the problem? > > > > > > P.S. I'm trying to setup pesos and it seems like python3.3 is a > > requirement > > > but it isn't mentioned anywhere. > > > > > > > > > On Tue, Jul 22, 2014 at 1:45 AM, Tom Arnfeld <[email protected]> wrote: > > > > > >> Hey, > > >> > > >> I've started to try and finish off the work @wickman started around > > >> pesos[1] and compactor[2] - pure language bindings for mesos and > > libprocess > > >> in Python. It's currently far from finished, but have fun into a brick > > wall > > >> around libprocess. If anyone could shed any light that'd be great. > > >> > > >> To start with, I saw the framework register but disconnect > immediately. > > >> From a quick chat on IRC someone mentioned this could be related to > not > > >> keeping the inbound message connection open, the one that sends > > >> mesos.internal.FrameworkRegisteredMessage. In doing this, the > framework > > >> does register with the master and shows up in the UI – however no > > further > > >> messages are received at all. I'm keeping the outbound connection open > > >> already. > > >> > > >> Mesos seems to think it's sending offers (they show up in the logs and > > are > > >> showing in the Offers page) but the master never gets past there, and > > the > > >> framework never receives the HTTP connections. No doubt this is a bug > in > > >> the socket logic on my end. Struggling to find my way through the > > >> libprocess source to figure it out. > > >> > > >> Any pointers would be much appreciated. > > >> > > >> Thanks! > > >> > > >> Tom. > > >> > > >> [1] https://github.com/wickman/pesos > > >> [2] https://github.com/wickman/compactor > > > > >
