04:07 < jonpsy[m]> During my time in tensorflow-addons we used to have a docker image to replicate all the tests in local machine itself. Have we thought of something similar?

10:55 < Aakash-kaushikAa> I mean it shouldn't be that hard to make docker images but do we need them ? I mean most of us check the complete viability on PRs itself when the tests are run.

10:56 < rcurtin[m]> agreed, the tests are already self contained

11:09 < shrit[m]> jonpsy: I think in Tensorflow scenario, it used to have a lot of dependencies (Correct me if I am wrong), therefore docker container is good if it has all inside

11:29 < rcurtin[m]> if I'm not mistaken, there does exist a container that contains all of mlpack's dependencies for easier building, but there aren't that many dependencies (certainly not as many as tensorflow) so it is a pretty simple container

11:51 < jonpsy[m]> Aakash-kaushik (Aakash kaushik): Fair point, but having everything tested locally seems like a major plus to me.

11:51 < jonpsy[m]> shrit rcurtin We do !? :D My main idea was, lately all IDE support coding directly inside the container, so we can totally eliminate all the installation related issues AND have all the tests done locally. Setting up the dev environment, especially in Windows can be punishing ( I recall even you had problems with that Ryan :) ). That's just my opinion though, so feel free to shoot critiques :)

12:38 < shrit[m]> jonpsy: Do you mean distributing mlpack as docker container?

13:00 < Aakash-kaushikAa> I think i also saw a mlpack docker container but i think that was on the previous site I can't really find it on the revamped one, but i could be totally wrong here.

13:01 < jonpsy[m]> <shrit[m] "jonpsy: Do you mean distributin"> It does overlap with that idea. I meant, for ex: we have our Remote development container right? I want to have their docker image so that i can make a container and directly code inside them.

13:01 < Aakash-kaushikAa> But except windows I don't see people facing issues while developing mlpack or running tests for mlpack.

13:03 < jonpsy[m]> I think previously this month we had some users complain about the Cereal dependency issue. And user have complained a bit in the past about boost linking.

13:03 < jonpsy[m]> What my fantasy land proposes is total elimination of build related issue, so user can just hit "mkdir build, CD build and make" In the container just like Github's codespaces.

13:05 < zoq> We have a bunch of images, that have all the dependencies - https://hub.docker.com/u/mlpack but it's not really documented, so I guess that's one thing I should do.

13:06 < zoq> That said I also have a solution that connectes VS Code with Google Colab, which also installs everything for you and you allows you to work remote on a Colab but with VS Code.

13:10 < jonpsy[m]> <zoq "We have a bunch of images, that "> I have a silly question, does these image are always up to date with mlpack master?

13:14 < zoq> Not yet, no.

13:15 < jonpsy[m]> Sorry I didn't pose the above question correctly

13:16 < jonpsy[m]> <zoq "Not yet, no."> I see. What's your opinion on the development on container idea?

13:16 < jonpsy[m]> * Sorry I didn't pose the above question clearly.

13:30 < rcurtin[m]> jonpsy: on Linux the dependency issues should truly not be hard... you need CMake, a compiler, boost, armadillo, and ensmallen... if you don't have any of those last three, CMake now autodownloads them

13:31 < rcurtin[m]> that said, the container does exist, and so if you'd prefer to use that it is there, but I don't think it helps Windows developers

13:31 < rcurtin[m]> (there is no Windows container)

13:32 < jonpsy[m]> Dockker doesn't support windows image........?

13:33 < rcurtin[m]> I mean I have no idea if it does or not, but I can say that to my knowledge, regardless of whether Docker has support for it, nobody has built an mlpack Windows container

13:34 < jonpsy[m]> I see

13:34 < jonpsy[m]> Is it because it's cumbersome or it's impossible?

13:34 < rcurtin[m]> I think it's because nobody has done it

13:35 < rcurtin[m]> I have no idea if it's cumbersome or impossible... at least from my angle, I don't have any particular motivation to, since I am not a Windows developer :)

13:35 < zoq> To have a Windows container you have to have Windows Server, which I think is not common for our userbase.

13:36 < rcurtin[m]> personally, I feel like anyone who can develop C++ and operate a C++ compiler shouldn't have too much of an issue installing the couple dependencies to develop mlpack, so at least from my end I haven't put much priority into making development easier (it's already pretty "standard" for a C++ library... at least from my perspective, which who knows, could be 15+ years out of date?)

13:36 < rcurtin[m]> if someone did want to make modifications to make things easier, I'm all for it, so long as we consider implications carefully---for instance, the autodownloader actually has lots of implications if we are downloading compiled code

13:37 < rcurtin[m]> (luckily it downloads header only code... but... even there there is trickiness, as if we download Armadillo automatically via the autodownloader, the system may have no LAPACK/BLAS available and various matrix decompositions and operations will not be available)

13:37 < zoq> Also I think once we removed boost completely, I'm not sure you encounter a lot of problems.

13:37 < jonpsy[m]> <rcurtin[m] "personally, I feel like anyone w"> Perhaps you're right, and it's only expected of C++ users. Docker container development is more famous on the python side of development, so I kinda imported my ideas from there

13:38 < rcurtin[m]> yeah, in Python-land, wrangling and managing dependencies gets super hard, especially when C/C++ code is in the mix (like it is with TF)

13:38 < rcurtin[m]> this is part of why I have had such problems building a Python wheel for Windows for PyPI for mlpack... I haven't had time to fight with it recently, but it was a giant awful nightmare

13:39 < jonpsy[m]> <rcurtin[m] "this is part of why I have had s"> I won't even try and imagine 😄