Indeed, that is a problem. More reason then to be transparent to the user, and have he/she have complete control over the updates. If the user tries ups something and it does not get the latest version, we should tell him that, and that is it (the package manager does that, but only if the user wants to install a specific version). - or at least give the user that option, with a simple flag, like add -q, up -q.
I know when I’m using my linux distribution that many packages are being hold back because I do not have the latest distro. But I have the choice to when/how update things, without that messing up with my daily use of the system.
(and, as pointed by @Lilith, we have a situation where even adding a dummy package may trigger a lot of work, without having anything to do with any compat bounds).
I have a friend that had that kind of issue and 1.7 improved things a lot. It does not seem to be the same issue I have in that cluster.
Make ]add more conservative about updating unnecessary packages by default
Add ]activate --reproducible name which prevents name from stacking with global (i.e. has the impact of removing @v#.# from Base.LOAD_PATH in only in name)
Stop discouraging global environment usage
Where does it fall short of solving everyone’s problems? Where does it fall short of the status quo?
This was discussed in messages 44, 47, and some others.
It’s not working and falling back to getting the registry with git, i.e. exactly what it was doing before. Do you have some firewall or similar interfering? (I’m not an expert on SSL and certs stuff, hopefully someone else can help out with understanding that error.)
Not that I am aware of or have any control over. I will try to reach to the maintainers to see. If anyone has any hint on how to get more information, that would be nice, I would be able to provide them more data to track the issue.
One curiosity: is the new registry system ported to 1.6?
I’m not sure exactly, but I wonder if there isn’t a key exchange that occurs which is time-sensitive (like a symmetric key is negotiated and the far server says it’s good for 10 minutes) which then on the local end appears to be expired immediately. Get the time fixed, and see if it works! it’s definitely suspicious that the time is off!
Downloading github repositories seem to be particularly problematic. Any idea?
The tarball of julia downloaded now at 7Mb/s, but one repository downloaded at 280Kb/s (the same goes for the tarball of the release of that same repository).
It’s kinda unheard of to have a high performance cluster that has 7Mbps connection to the internet. So maybe talk with the administrators and see if they’ve got a serious networking issue. Like maybe there’s a network broadcast storm they don’t even know about? That’s definitely odd.
I have to say that I find it frustrating that Julia defaults to updating the registry, and potentially updates all of my packages (if new versions are available, which is often the case) whenever I want to install a single new package. I really only want it to update if I specifically run pkg> update — otherwise, Julia should assume I’m happy with the versions I currently have.
A workaround that does what I want is to put
Pkg.UPDATED_REGISTRY_THIS_SESSION[] = true
in your ~/.julia/config/startup.jl, but I wish this was the default.
One thing that might improve the user experience is to expand the documentation on environments, focusing on how to use them effectively, and not on how they are implemented. Currently, neither Julia’s nor Pkg’s manuals include the terms local environment or temporary environment. activate has only a short reference section in Pkg’s documentation.
