On Thu, 2023-03-30 at 23:11 -0400, Curran McConnell wrote: > Thanks so much for breaking that down! > I will take a closer look at the distinction between the different > kinds of > "package". There is a good likelihood I won't ever need this to be a > "standard" package, but either way that is a helpful way to frame the > problem. > > Also, I didn't mean to start a private conversation--I haven't used a > Google group before, I think I might have misused the interface > slightly. > Should we repost this thread to the main chat in case other people > have > this question in future? >
No problem. I only interact with the group via email, but I'll CC this message to the list (sage-devel@googlegroups.com) so that the quoted conversation below shows up. > Best, > > Curran > > On Thu, Mar 30, 2023 at 4:23 PM Michael Orlitzky > <mich...@orlitzky.com> > wrote: > > > On 2023-03-30 12:43:45, Curran McConnell wrote: > > > Hi Michael, thanks for your explanation. I have a followup > > > question. > > > > > > You distinguish between creating a Sage interface to an external > > > library > > vs > > > writing a standard piece of Sage in Rust. > > > If my package exported a native Python extension module > > > (https://docs.python.org/3/extending/extending.html), packaged > > > via > > wheels > > > so the user never has to run the Rust toolchain themselves, would > > > that > > fall > > > into the "interface to an external library" category, from your > > > point of > > > view? > > > > The devil is in the details but I'd bet that it does. > > > > The two things that would cause problems are, > > > > 1. Adding an *.rs file directly to sage.git. > > 2. Creating a type=standard package that needs to compile an *.rs > > file. > > > > Sage is slowly modularizing, and if you look in build/pkgs, you'll > > see > > a list of separate "packages" that can be installed. The > > terminology > > is a bit confusing nowadays, but if you look in (for example) > > build/pkgs/flint/type, you'll see "standard". A standard package is > > one that is essentially a part of sage itself. Those packages > > should > > also not be written in rust, at least for now, since everyone needs > > to > > be able to build them from source. > > > > In your case you probably just want people to be able to `pip > > install` > > your package and to have it show up in their Sage interface. That's > > possible without an entry in build/pkgs at all, and you can > > implement > > it however you want. So long as it's not shipped with and an > > essential > > part of sage itself, an independent python module/extension has a > > lot > > of freedom. > > -- 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/f5ee21ebea936f0fe886d6b4a0e573a84cdf2b4d.camel%40orlitzky.com.
