I don't use lxdock anymore

[ghost]

@ellmetha are you still using it?

I've had second thoughts about the usefulness of creating lxdock. Sure LXD isn't supported on vagrant (there's a new vagrant-lxd plugin but it doesn't look like it works well), but I've been working directly with LXC and vagrant-lxc recently and, as a matter of fact, it works rather well.

Sure, the whole "box management" part is tricky with LXC/LXD and a vagrant-lxc user has to create her own boxes. Sure, LXC is hard to set up properly. But as long as vagrant has the virtualbox fallback driver, that doesn't matter much: users will go through complicated setups if they need the speed.

Also, I don't like the idea of using the LXD layer when I don't need it. Also, building Go stuff is a PITA on Gentoo.

I think I'd rather spend my time on vagrant-lxc (it doesn't support unprivileged containers yet).

Since I don't see activity on your side either, does that mean that lxdock became unmaintained? If so, we should indicate it in the README. Someone might want to pick it up.

[ellmetha]

I don't use it anymore neither. What you said regarding vagrant-lxc makes sense so yes, let's write somewhere that LXDock became unmaintained. 😉

[robvdl]

I still use it because I never had much luck with vagrant-lxc in the past and due to it's lack of maintenance and the difficulty I had to install it in the past, this how I initially actually found lxdock in the first place :) I am a bit busy right now with a bunch of Wagtail sites though, but for some crazy reason I always had a burning desire to rewrite it in Go, or is that just madness? You probably want someone that will continue the existing Python codebase though.

[ghost]

@robvdl if you get to feature parity with the current python version, I don't see the harm in rewriting it (other than what some people would see as needless efforts, but I understand that burning desire: what the hell, let's make useless things!).

But you might want to start a new project altogether. This way, you wouldn't be tied to implementing some features of lxdock you might like less.

[robvdl]

I think lxdock should stay as it is for the time being, keep it Python, if I was to do a rewrite, it will be next year and it will probably be best under another project name entirely. And yes I probably would only start with implementing the features I cared about the most, which would be to keep it as simple as possible for development containers, I would particularly focus on the dev mount permission mapping because that is what I always struggled with and since I see lxdock as a development only tool, to me it's more important that things work out of the box than being ultra secure, I never liked the whole setfacl thing touching every file in my git repo for example.

But anyway, because of changes like this, is exactly the reason why lxdock should stay as it is, keeping the existing Python codebase as is.

Although I personally don't think a Go rewrite a waste of time as one of the things holding lxdock back from time to time was waiting the python bindings for lxd, in Go you wouldn't need the Python bindings so it's one less moving part to depend on, also it's much easier to release a binary than getting people to pip install lxdock into a virtualenv.

But anyways, lxdock is under an organisation which is perfect, you probably want to find more than one person to manage incoming pull requests and answer issues, I'm happy to pitch in there but I am not entirely sure if I am able to manage it on my own because of my existing workload.

[ghost]

@robvdl fair enough, you're in!

[nkabir]

Agree on all counts, @robvdl. I prefer a code-reviewed release process.

[robvdl]

Just putting a note here for people to read. The project isn't unmaintained but it may be a while before the 0.5 release, we have some plans of where to take the project but right now the immediate issue is that the tests stopped working on Travis CI and that is because Ubuntu have deprecated the PPA for LXD and we are having some issues trying to get a commit past that will use the Snap version of LXD on Xenial. Once that is through, I can remove the unmaintained notice from the README so please bear with me.

[adam-stokes]

@robvdl let me know if you need any help, we use snap lxd in our tests for conjure-up https://github.com/conjure-up/conjure-up/blob/master/.travis.yml

travis-ci is a little iffy sometimes with snap on 14.04 but usually works well enough if you have to restart a test every once in awhile.

[robvdl]

@battlemidget thanks for that, I can follow this, I probably don't need all of it but there is some useful stuff there that may help us. I am just wondering why in your Makefile you are installing Python 3.6 from a PPA. Is this still necessary? Don't travis already provide Python 3.6?

[robvdl]

@battlemidget we almost got there, with your advice I have managed to get snap lxd working on Trusty, but we're still running into this strange recursion issue while installing both pylxd 2.2.4 or 2.2.5, it doesn't seem to make a difference which version is used.

https://travis-ci.org/lxdock/lxdock/jobs/349757645#L867

Going to take a break from this for the moment, but will have another go at fixing it tomorrow, maybe the pylxd project has an issue regarding this.

The issue may be related to sphinx, as I also see sphinx in my traceback somehwere near the top.

astropy/astropy-helpers#319

edit: that seems to have actually fixed it, all I had to do to get past the recursion issue is pin Sphinx to version 1.5.6

[adam-stokes]

@robvdl circling back to this, travis-ci now supports xenial and we've not seen any problems in our testing of conjure-up using this method:

https://github.com/conjure-up/conjure-up/blob/master/.travis.yml

There's also examples in there for testing against newly released python 3.7