The problem that it *causes* is that people think that Sage has somehow managed to install an ancient ipython-5.0.0 in their ~/.sage directory. The user that reported this was indeed having problems because of an out of date ipython thet they had installed with %pip. The python package was installed as a --user package in ~/.sage. That is where the macOS app installs all pip packages, being disallowed from putting them into the app bundle itself because that would break the signature and macOS would then refuse to run the app..
The old version of ipython caused the new app to crash with the rather amazing error message "object of type List is not iterable". When the user removed their ~/.sage directory everything worked as expected. But then, after starting Sage, they checked to see what was actually in the directory, and were alarmed to ",find" that Sage had re-installed ipython-5.0.0. As I said, this idea confuses users, and understandably so. It was not a great idea. There were so many other, better, ways of naming the directory. Maybe for the next Sage release I will move the pip packages to ~/Library/SageMath-X.Y. That won't stop Sage from creating ~/.sage/ipython-5.0.0 but it will remove the motivation for users to look in the .sage directory and get confused. - Marc On Monday, April 1, 2024 at 3:31:06 PM UTC-5 Nils Bruin wrote: > One scenario where I could see this being beneficial: > These configurations are written into `$HOME/.sage` (normally), so that is > not a location that is predicated by a venv or a localized subdir. If a > user is using two different sagemath installs (e.g., one system, the other > for development) that have incompatible ipython configs, they need to live > in places that allow peaceful co-existence. This would do it. I agree the > version number can look confusing, It seems like a historic artifact that > we didn't need to change our ipython configs since version 5.0.0, probably. > It looks to me like a fairly arbitrary choice how to mark that directory > name. Not changing it would be the easiest solution, but if someone wants > to make an argument that another naming convention has benefits (following > common practices that have since evolved?) it could be changed, at the > expense of everyone with an install needing to change locations of files > they already customized. So based on that, I think the best time to change > it (if at all) would be when an incompatible change in config is happening > anyway. > > > On Monday 1 April 2024 at 12:20:16 UTC-7 Dima Pasechnik wrote: > > > I must say I don't know what kind of problems these versioned names are > meant to solve. > > > > >On 31 March 2024 15:23:24 CEST, Marc Culler <marc....@gmail.com > <https://groups.google.com/>> wrote : > > >if [ -z "$IPYTHONDIR" ]; then > > # We hardcode a version number in the directory name. The idea is > > # that we keep using the same version number as long as that is > > # possible. Only when some future IPython version really requires > > # a new structure for the $IPYTHONDIR should this version number be > > # changed to the new IPython version. > > export IPYTHONDIR="$DOT_SAGE/ipython-5.0.0" > >fi > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/fe00c9f6-0b3f-4adb-92e8-817c022873b2n%40googlegroups.com.
