Hi,
Is it possible to not install any library directory when you* install R the next time? For some reason, I can't delete the main directory from my .libPaths() and this creates weird and unsuspected bugs with some of the bioconductor packages.

*you a.k.a whoever is going to be in charge of this

Yeah, indeed, it’s a very tedious problem. You can hack .libPaths though:

lib_env = environment(.libPaths)
lib_env$.lib.loc = your_library_path

I don’t recommend this as a sustainable solution, but it’s a workable temporary fix to re-install packages locally that are also present (in an outdated version) centrally.

@klmr Thank you so much! I was getting crazy with bioconductor.

There are some rough patches at the interface between prefix- and user-managed packages. This is, unfortunately, unavoidable.

For R packages specifically, we have the following setup:

system libraries --linked-> R+included packages [prefix] --depends-> other R packages [user]

This also means that prefix takes care resolving all system dependencies up until the included R packages (like causing a rebuild of R if one of the libraries that a package depends on changes). But we will always have this interface between prefix and user-managed installs somewhere, and there thing are going to break now and again (and the point of prefix is to be up-to-date, so if you want an R that never changes install your own or find an available install).

I'm open to suggestions on why we should move the prefix-user boundary between the R and the included packages above (this is supported by prefix), but I will need more to go on than

creates weird and unsuspected bugs with some of the bioconductor packages

especially because base should not be updated manually [i.e., as packages outside updates of R] according to the docs.

@mschubert: I read you but not sure we got each other here. At least, I don't get your explaination in it's whole.

My issue here was that bioconductor was not getting updated, it was stuck with the 3.2 version while R was 3.3 and biocLite() should have allowed the update by itself.

However, it was trying to update prefix packages while I don't have writing access to it and wouldn't pursue, the usual fix when I deal with the R provided by systems is to remove the system path from .libPaths(), thing that I can't do for some reason with the prefix version of R.
This is a bit unclear to me why in one case I can remove path from .libPaths() manually and not in the second case. I supposed that it is due to some options while the compilation.

In any case, I just needed to upgrade my version of bioconductor, which I managed once I removed the prefix path from .libPaths() thanks to Konrad's hack. So I don't mind using the hack every now and then when I need to do some major upgrade. It's not like I need to play around with library paths everyday! :p

Packages from CRAN work as expected with the .libPaths() as described in the README (and if you don't set it, it should ask you to use your personal library).

If that doesn't work in Bioconductor it's a bug in their software. Is it the same as https://support.bioconductor.org/p/65622/ (that's supposedly fixed)?

Mitra’s problems indicate that there are centrally1 installed Bioconductor packages. Maybe it’s BiocInstaller?

1 Meaning, at a location that R cannot write to when executed by Mitra’s user account.

There are no centrally installed Bioconductor packages and the only time there were is when you put them there by accident ;-)

There are, however, base packages that Bioconductor wants to update (which it should do in the user dir, and if it doesn't, that's a bug).

Oooh, I see. I agree that that’s a bug, but it’s especially weird in light of what you wrote above:

especially because base should not be updated manually [i.e., as packages outside updates of R] according to the docs.

What the fuck, Bioconductor?

Just to clarify my situation;
@mschubert I initialise my library path at start, however, while for R provided by Systems, it does mean that everything is on my own path, for prefix, for some reason, it only adds to the available path.

@klmr: one of the two culprits was nlme (I forgot what was the other package) that bioconductor tries to update in the 'system-wide' installation and even though the correct version of the package is living on my personal library, bioconductor doesn't care at all. It is super annoying, but I had the feeling that bioconductor people are sadistic/control freaks in some extent and don't really pay too much attention for particular cases like we have in EBI.

As I said, your hack allowed me to remove the prefix library from my path temporary and do the upgrade and now everything is working happily again. I don't have any issue anymore. We should just write down this hack somewhere for future generations.

(Edited for typos and missing words :p)

No, that should be fixed upstream. Setup like ours with shared non-write R and user Bioc is common.

Please report this to Bioconductor.

Well, I have added it to my todo list, I am not very eager to contact the bioconductor people. I might just email Wolgang directly.