Do you still (?) want reports of successes/failures/hick-ups. I always
seem to find the last :)
rrogers
On 4/22/22 11:16, seb@gmail.com wrote:
(./sage -i should be deprecated and removed…)
— or just have ‘sage -i xyz’ do whatever ‘make xyz’ now does, perhaps.
+1
Replacing
I haven't been following the copy and paste thread, but I'm in favor of
keeping sage -i xyz functional, even at the cost of some hacks in our
codebase. There are a lot of existing Sage users who are familiar with
that command as a mechanism to install optional packages, even if it's not
a priori d
On Fri, 2022-04-22 at 08:16 -0700, seb@gmail.com wrote:
>
> (./sage -i should be deprecated and removed…)
>
> — or just have ‘sage -i xyz’ do whatever ‘make xyz’ now does, perhaps.
>
> +1
>
This only works if you don't ever want to e.g. rename sage to sage.in
to fix the copy & paste from t
On Friday, April 22, 2022 at 8:16:08 AM UTC-7 seb@gmail.com wrote:
> (./sage -i should be deprecated and removed…)
>
> — or just have ‘sage -i xyz’ do whatever ‘make xyz’ now does, perhaps.
>
> It has been repeated many times that "sage -i" either "is" deprecated or
"should be" deprecated.
I
(./sage -i should be deprecated and removed…)
— or just have ‘sage -i xyz’ do whatever ‘make xyz’ now does, perhaps.
+1
Replacing sage -i xyz by make xyz sounds like assuming *all Sage users are
developers*. make xyz doesn’t work if the current directory isn’t SAGE_ROOT
or if make doesn’t ex
On Fri, 2022-04-22 at 01:03 -0400, ph h wrote:
>
> Is this use case scenario, (running a script before building anything)
> documented or undocumented?
>
I'm not sure if it still is, but running things like "sage -b" and
"sage -i" was for 15+ years the documented way to build parts of sage.
Thes
Hi Vincent and Matthias,
I also think that we should migrate away from the moin moin wiki.
On Wednesday, April 20, 2022 at 6:42:58 PM UTC+2 vdelecroix wrote:
> Migrating the wiki as you propose
> will make it harder to leave trac.
>
I don't think that's true. Migrating the wiki elsewhere is t
