I have a Julia repo, and I created a Project.toml file in the binder subdirectory of the root directory of my repo. This seems to work for specifying the version of Julia to use, however, the packages listed in the Project.toml file are not loaded when the Binder is launched. However, if I move the Project.toml file to the root directory of the repo, then it seems to work properly.
Is this known behavior? A bug? Is there any workaround? I’d prefer not to have the Project.toml file in the root directory.
Hello, I have observed a very similar behavior.
I have a repo with an unregistered Julia package that has a Project.toml.
I want to set up a binder for this repo that should also contain some other packages that I don’t want to have as dependencies of my package (e.g. Plots.jl). I tried to add a folder called binder with another Project.toml containing further packages. But this doesn’t seem to be used by binder but only the Project.toml in the root of the repo is used.
Binder can’t recognise files stored in multiple locations, e.g. root AND a subdir, it has to be one or the other. I would recommend having your binder config files in a separate branch which is built by binder, then use nbgitpuller to pull in your content. You can find more info and an example here: How can I separate my Binder setup files from my content? — Binder 0.1b documentation
thanks for your answer. Just to make sure I understand correctly:
In my case I want binder to use the Project.toml in the “binder” folder and to ignore the one in the root of the repo. But this is not possible and binder will still only use the one in the root? Because here it says that if there is a “binder” folder, the config files in root should be ignored.
Hmmm, it could be possible but if it’s not working, perhaps we have a bug? Could you test by temporarily removing the Project.toml files/binder directory in turn and seeing which packages are installed vs which ones you’re expecting to be installed? You can test locally with repo2docker rather than waiting for mybinder.org to build it: https://repo2docker.readthedocs.io
so I tried some things and it seems the problem is that Binder is not correctly installing the dependent packages if the Project.toml is in the “binder” folder.
I tried setting up a repo with no Project.toml in root but only in a “binder” folder and then things don’t work as expected.
Main has a Project.toml in root with only 1 of the 2 required packages in it and another Project.toml in “binder” that has both required packages in it (this is what I would like to do)
justroot has the Project.toml with both required packages in root: Everything works fine
justbinderfolder: Only has a Project.toml with both packages in the “binder” folder, none in root. Packages are not working.
Is this the expected behavior? From the Github issue I mentioned above, I would expect all three branches to work the same, or am I misunderstanding something or doing something wrong?
Hello,
I have the same problem with binder. I want to start my repository in binder with a Project.toml from a subdirectory. Is there any solution to the bug from above?
Or alternatively is there any other solution for this but using an extern repository?
If there is anything that already answers my question, I’m sorry I didn’t find it.
As a distinguished contributor, please consider creating the issue yourself if you see that a new user is not able to do so. Now more than half a year is past and other users like me run into the same issue, just because it was not properly reported back then, which seems unnecessary.
Please remember that everyone in this community, distinguished contributor or not (which I actually wasn’t at the time this thread was posted), is providing their time on a voluntary basis. A lack of response to a thread is not an indication of inability to open an issue, but more likely that the time was not available to follow-up on this for either party. A great benefit of having the user report their own issues is that they will have the context of their own setup that will help the developers understand what they were trying to achieve and why it could’ve gone wrong - and no one but the user is able to provide that context. Without it, a lot of time is needed to replicate issues to get to a point where we can begin to fix them. The OP did not ask for any assistance with opening the issue so of course it fell off my radar amongst all of the other priorities I have. It is unfortunate, but it happens because we are all human.