Hi Volker, On 2013-01-12, Volker Braun <vbraun.n...@gmail.com> wrote: > Deprecation works in the Sage library because it is being tested.
Hey, I was talking about deprecation in the Sage library!! What I suggest is to find a way such that sage: from sage.misc.misc import SAGE_DATA imports SAGE_DATA with a deprecation warning, rather than raising an ImportError. I think this could be easily implemented using lazy_import. The value of SAGE_DATA should of course be the name of the folder containing data, which apparently became SAGE_SHARE. > Nobody > can test optional spkgs against a wide range of past and future Sage > versions. The users do. And it would be nice if the user just sees a deprecation warning, when an optional package tries to use stuff *from the Sage library* that recently became deprecated. In that situation, the package would still work (in spite of the warning), which is much better than making the package unusable. > Case in point, no Linux distribution makes any promises that packages from > other versions of their distribution work. Again: I am talking about a published version of an optional spkg that does not work with *any* published version of Sage. It will only work with a version of Sage that will hopefully be released soon. And I think such a situation should be avoided. > Imho thats the proper solution, and not propping an > untested deprecation framework and an untested dependency framework on top > of the spkg system. I was talking about using the *existing* deprecation framework in the Sage library for deprecating import statements. Nothing else. Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
