And … that’s it! You should have a full suite of IGWN software on your computer. Now you can run tutorials from the Open Data Workshop locally on your laptop. Please try it out, and let us know how it goes.
I checked the Option 3 of the Setup (odw-2022/setup.md at main · gw-odw/odw-2022 · GitHub), it seems to work (and to work quite easily), but maybe I’m biased by the fact that the conda environment was already installed on my mac. Anyway, everything else seems to be ok, the instructions are clear and the tutorial (at least 1.1) works as well.
I am trying to setup the conda environment on mac, everything else works fine at first, but when i get to the step where i will have to enter “conda env create --file igwn-py39.yaml”, the terminal returns:
It seems like it could not install the entirety of the packages on the stack. I can only think of a network connection problem. Can you post as well the commands you typed? Deleting the environment and creating a fresh new one may also help.
@harryyeh I’m sorry you are running into a problem!
I just tried it on my mac, and it worked for me. Sometimes, conda packages can go missing for a few hours due to network and/or server issues. I’d encourage you to try again after 24 hours, and let us know if the problems persists.
Related to this issue, I think Apple removed Rosetta (the osx-64 to arm translator) in one of the latest updates because I used to be able to make it work before with the previous yaml, but not after I last updated the OS.
Note: as documented, the osx-arm64 environments are provided on a best-effort basis only, and may be incomplete with respect to the linux-64 or osx-64 environments. If there are packages that you wish to find in osx-arm64 that currently aren’t included, please (a) coordinate with the maintainers of the conda-forge recipe for that package to have it built for osx-arm64 then (b) contact a member of IGWN Computing (e.g. me) to get that package added to the distribution.
I followed the instruction in odw-2023/setup.md at main · gw-odw/odw-2023 · GitHub (option 3) to install the softwares on my macbook air M1. The installation process went through smoothly without any errors or warnings. However, as I launch jupyter lab in igwn-py39, I got the following error messages (sentences starting with ‘E’) from time to time (but not always):
[C 2023-03-17 07:48:40.739 ServerApp]
To access the server, open this file in a browser:
Or copy and paste one of these URLs:
[E 2023-03-17 07:48:42.580 ServerApp] Error unpacking user from cookie: Expecting value: line 1 column 1 (char 0)
[I 2023-03-17 07:48:42.581 LabApp] Generating new user for token-authenticated request: 0e9db6f50c624aef9fdf3b99a3709caf
[E 2023-03-17 07:48:42.581 ServerApp] Error unpacking user from cookie: Expecting value: line 1 column 1 (char 0)
[I 2023-03-17 07:48:45.461 LabApp] Build is up to date
Before that I also got the warning messages (sentences starting with ‘W’):
[I 2023-03-17 07:48:39.983 ServerApp] Package nbclassic took 0.0000s to import
[W 2023-03-17 07:48:39.985 ServerApp] A _jupyter_server_extension_points function was not found in nbclassic. Instead, a _jupyter_server_extension_paths function was found and will be used for now. This function name will be deprecated in future releases of Jupyter Server.
[I 2023-03-17 07:48:39.985 ServerApp] Package notebook_shim took 0.0000s to import
[W 2023-03-17 07:48:39.985 ServerApp] A _jupyter_server_extension_points function was not found in notebook_shim. Instead, a _jupyter_server_extension_paths function was found and will be used for now. This function name will be deprecated in future releases of Jupyter Server.
Can someone tell me what caused the above problems and how to fix them?
Hi, I have the same type of laptop and I have tried to reproduce the error but I don’t get this kind of error. However, I have the impression that if I tell conda that the operating system is osx-arm64 and not the default osx-64, the notebook seems to run a bit faster and maybe it solves also the problem you have.
To check which OS you are using you can digit conda info (after having activated your environment); to change it, you have to activate your environment and then digit conda config --env --set subdir osx-arm64 (it will work only on the current environment). Hope this help.
Another consideration: which yaml file are you using for installation? As mentioned in previous messages, there is a specific version for M1 which you can find on osx-arm64, can you try using this one? ( the setup page points to a different yaml because it was written before the addition of the osx-arm64 architecture and it has still to be updated, but we will do before the workshop starts)
@Agata Thank you very much for your help. I think the problem disappears after reinstallation of the igwn-py39 using the osx-arm64 version of the yaml as suggested by you. I do it as follows:
I download the igwn-py39.yaml for osx-arm64. I delete the existing igwn-py39 enviroment by “conda env remove --name igwn-py39”. Then, I run “conda env create --file igwn-py39.yaml” with the new yaml file. However, it does not go through because of “Soving environment: failed” and “ResolvedPackageNotFound”.
Then, in a terminal I run “arch” to verify that the architecture in my M1 is arm64. Indeed it is. However, as I run “conda info” (in the base environment, since the igwn-py39 was already deleted), it dispays “platform : osx-64”, not the expected osx-arm64 (I don’t understand why). Then, in the base environment, I run “conda config --env --set subdir osx-arm64”. After doing that, I run “conda info” and it displays “platform : osx-arm64”. With the above preparations, I run “conda env create --file igwn-py39.yaml” again. This time the installation goes through successfully. After activating the new igwn-py39.yaml, I can launch the jupyter lab without seeing a problem.
However, I still have a concern. As described above, in the base environment I run the command “conda config --env --set subdir osx-arm64”. From the internet I found that people usually use this command line in a virtual environment (you also seems to indicate this). Will it cause problems by running it in the base enviroment? Basically the line tells conda to install only “arm64-version” softwares, right?
Hi @lxl, glad it worked! Your post will be useful for many other users, me included
About your concern, I am not an expert but as far as I have understood I think that you are correct and that conda config --env --set subdir osx-arm64 is just a way to tell conda to install osx-arm64 version softwares. Since M1 is still recent enough, it is possible that for some packages the version osx-arm64 does not exist yet or is not mature enough so in that case we should still use the default osx-64. However, I guess that in the long run it would be better to use osx-arm64 to be sure that everything works in a proper way.