Changing environment in Kaggle? (Option Disabled) - jupyter-notebook

A kaggle (private) notebook of mine was created an year ago so it uses an environment (package versions) of the date when it was created. To use the latest package versions, there's an option to change Environment Preferences from within the Edit page of a notebook. But turns out, the option is disabled.
The only other way to get the latest package versions now is to upgrade them all manually by pip calls from within the notebook for each module. This was working fine until I required a newer version of pandas. You need to upgrade any module before importing in kaggle to use the upgraded version, otherwise it uses the old one. And pandas is one of the few libraries that is preloaded with every notebook start, so an upgrade call to it still does not use the latest pandas. What can I do here? Any tips on how I can enable the environment preference option?

It was a problem on Kaggle's end. They have rolled out a fix.
More details
If it happens again, create a thread on kaggle forum I guess, just like I did.

Related

How to make sure the user of a shiny app is using the right package versions in R

Due to recent experience with several bugs created by updating packages, I wonder what the best approach is for the following problem:
I currently provide a stand alone version so to say of my shiny App (just the script files to run it locally) and run a long list of require() functions to load / install the needed packages. However, in the end I would like to use fixed package versions to avoid bugs created by changes in packages.
Is there a way to ensure that the user, who may have older or newer versions of packages on their computer, is using the right version of all the packages my app needs?
You can consider using packrat: https://rstudio.github.io/packrat/.
Unfortunately, private libraries don’t travel well; like all R
libraries, their contents are compiled for your specific machine
architecture, operating system, and R version. Packrat lets you
snapshot the state of your private library, which saves to your
project directory whatever information packrat needs to be able to
recreate that same private library on another machine.
Short tutorial:
RStudio - File - New Project - New Directory - New Project - "Do: use Path" - Create Project
Enter in the R(Studio) console:
Code:
packrat::init()
.libPaths() # test if libpath has changed
install.packages("reshape2") # installs within one of the packrat libpaths
Installing package into ‘C:/R/packRatTest/packrat/lib/x86_64-w64-mingw32/3.4.3’
Assumption would be that you can use and share RStudio Projects, but i think it would be hard to work without them anyway ;).
Try writing your shiny app as a package. You can, somewhat, control that through the description file.
Since you said you're using script take a look at: https://github.com/chasemc/electricShine
Even of you don't use it, hopefully looking at the code will help for things like setting the download repo to be a specific MRAN date.

Programmatic check of R package version

I'm building an Rmarkdown document reliant on a frequently updated data package that's hosted on github.
How do I make sure that the document is always built using the latest version of the package, without installing the package on each build?
You can see the list of commits to a package by getting the commits page for the package. For example,
https://github.com/tidyverse/dplyr/commits
shows that there were commits today. If you save a copy of the top hash in that response (currently af75177), and then update whenever it changes, you should be sure to have the latest version.
However, this is likely a bad policy. The package is not necessarily in a working condition after a commit: perhaps the author is planning another one a minute later to finish some update. It's much safer to use update.packages() and only get the updates that are judged to be stable enough to be sent to and accepted on CRAN.

How to update julia 0.4 without pain?

Recently, I want to update my current 0.4.X version to latest 0.5.0. What's the best practice to accomplish this job?
Do I have to first remove my current version before installing the new one?
What about these installed packages, do I have to reinstall them one by one? Can my IDE (like Atom) support the new version automatically (or only with slight modification)?
Take the .julia/v0.4/REQUIRE file and plop it in .julia/v0.5, and then when you Pkg.update() it will add all of those packages. You might need to do using Atom in the REPL in order to have Juno properly re-compile before using it.

some issue with using atom sync-settings tool

With the risk of me misunderstanding something, I can't get my packages to sync. I went through the following scenario:
I install new packages on Machine 1 and upload the settings through the "Sync Backup" command in atom. I can see that the new packages are listed in the packages.json file in the gist.
On Machine
I restore the settings and can indeed see settings being restored, like keymaps. However I don't get my new packages. I have restarted and reloaded Atom without luck.
Are there any extra steps I need to take to get the new packages on Machine 2?
You can try atom-package-sync. It is a package that I created a couple weeks ago. It works a little bit like the synchronization of Google Chrome, you just login and it syncs your packages and settings automatically across all your Atom instances. It is based on package-sync but I find it easier to use.

Upgrading Tinn-R

I'm using Tinn-R version 2.2.0.2 and I want to upgrade to the latest version 2.3.4.4. I couldn't find any upgrade options in the menus of Tinn-R. So my question is: Is it safe to download and just install the new version? Will it overwrite my current Tinn-R settings?
As far as I can remember, the new version overwrites the existing one without a problem. In my case, however, the new version had many more problems in communicating with R console. For example it was very often the case that I was pressing the R send: selection button and nothing was happening.
I considered myself very lucky to have kept the Tinn-R 2.2.0.2 installer, and this is what I am using until now.
With every new version Tinn-R tries to preserve (as much as possible) the user's preferences related to old version.
These preferences are stored in a temporary file (INI). This file is never removed when the program is uninstalled.
Farrel is correct:
In the user guide it Clearly states que Should one uninstall the prior Tinn-R and then install the new version!
In time, it was released two new versions this week (with many new features):
3.0.1.8: http://sourceforge.net/p/tinn-r/news/2013/11/tinn-r-3018-released/
3.0.1.9: http://sourceforge.net/p/tinn-r/news/2013/11/tinn-r-3019-released/
I went through what you just did and switched because of it to notepad++ combined with NppToR.
Good luck,
Tal
Perhaps I am just a sheep who blindly follows but I stick to the instructions in the Tinn-R help file.
C:/Tinn-R/doc/english/user_guide/user_guide.html#basic_configuration_installconfigure
The easiest way to access the user guide is from the Tinn-R menu.
Help>Main>User guide>HTML
In the user guide it clearly states that one should uninstall the prior Tinn-R and then install the new version.

Resources