Re: [sage-devel] spkg-install's [was Re: Using a random number generator to tell the time!]
William Stein
<torn...@math.utexas.edu> wrote:
>
> On Sun, Oct 11, 2009 at 8:09 PM, Dr. David Kirkby
> <david....@onetel.net> wrote:
>>
>> Gonzalo Tornaria wrote:
>>> Would it make more sense to include something like busybox
>>> (www.busybox.net) into sage?
>>
>> I do not believe so.
>
> [snip]
>
>> Sage is designed to run on workstations and servers, not small embedded
>> systems. As such, would it not be better to support the Unix standard?
>
> My point is, wouldn't it be better if developers use the exact tools
> that sage is targeting?
>
> A standard is nothing more than an abstraction; the actual tools will
> always deviate from the standard in one way or another (if nothing
> else, by having more features available). When you write unix shell
> scripts, testing compatibility with varying real tools is already
> quite hard; testing compatibility with a standard may be impossible.
>
> The suggestion is, instead of targeting an abstract standard (posix),
> why not target a particular implementation of the standard. Busybox is
> just one option; there may be others (e.g. gnu shellutils/textutils).
> One advantage of busybox is its size which makes it reasonably "cheap"
> to include with sage.
>
> Take into account that most developers use gnu tools every day, so
> gnuisms are bound to show up one way or another. You'll have to be
> chasing them forever :-)
>
> Besides, IMHO, sticking with "pure posix" seems as silly as it would
> be sticking with python 2.3 (say) "because that's the lowest common
> version available in the supported targets".
>
>> BusyBox appears to support a subset of the options of the more common
>> GNU tools. That subset may not be sufficient and I feel would likely be
>> too limiting.
>
> Posix supports a subset of the options of the more common GNU tools.
> That subset is often not sufficient, and too limiting (and sometimes
> frustrating for users of GNU tools). YMMV :-)
>
> Just my 2 cents on this issue...
>
I really like Gonzalo's suggestion to think of specific tools and also
the actual people involved, rather than abstractions and standards.
Ideas for tools:
* a GNU toolchain
* Busybox
* Python itself
One can make a strong argument for writing a lot of the spkg-install's
in Python, which provides a powerful well-documented cross-platform
abstraction for all standard OS stuff (copying files, joining PATHs,
making tarballs), which is also easier to refactor. And this
abstraction is certainly more cross platform than POSIX. As an
example, the build system for the Windows port is written in Python
(by Blair Sutton) and it is nicely cross-platform in flavor.
For the Sage notebook code, during the last two weeks I've spent a lot
of time replacing things like "/" and explicit calls to "tar", etc.,
with OS-independent Python code (e.g., os.path.join; import tarfile,
etc.).
-- William
William Stein
<robe...@math.washington.edu> wrote:
>> This thread is mainly about Gonzalo's proposal that we target
>> something like busybox (or my suggestion "python") instead of POSIX
>> standard shell usage. Somehow it is amazingly difficult to keep this
>> discussion on track!
>>
>> Definitely your 1-3 are definitely a good idea though... it's hard to
>> argue with them.
>
> Ah, I got my threads crossed. I't still a bit unclear, are we talking
> about the scripts in sage/local/bin, or install scripts for the
> various packages, or both?
I think we are talking about both.
> I like the idea of moving towards using Python as the scripting/build
> coordinating language, but that might make using non-standard
> compliers and/or cross compiling even more difficult.
Why? I can only imagine it making things easier since we can structure
are code more cleanly and factor out common things. Anyways, one can
always do "os.system(...)" so shell capabilities are a subset of
Python.
This isn't a purely theoretical discussion, since the native Windows
porting work of Sage has a Python-based build system already.
I'm not arguing for changing anything in the Sage build system right
now. I'm just suggesting we should keep an open mind, so when some
incredible person shows up at a SAge days (say) who is willing to dive
in and do some amazing 1-month coding sprint to improve the build
system substantially -- say for a major Sage release like 5.0 -- we
are ready.
William
William Stein
<robe...@math.washington.edu> wrote:
> On Oct 13, 2009, at 6:45 PM, William Stein wrote:
>
>> On Tue, Oct 13, 2009 at 6:38 PM, Robert Bradshaw
>> <robe...@math.washington.edu> wrote:
>>>> This thread is mainly about Gonzalo's proposal that we target
>>>> something like busybox (or my suggestion "python") instead of POSIX
>>>> standard shell usage. Somehow it is amazingly difficult to keep
>>>> this
>>>> discussion on track!
>>>>
>>>> Definitely your 1-3 are definitely a good idea though... it's hard
>>>> to
>>>> argue with them.
>>>
>>> Ah, I got my threads crossed. I't still a bit unclear, are we talking
>>> about the scripts in sage/local/bin, or install scripts for the
>>> various packages, or both?
>>
>> I think we are talking about both.
>>
>>> I like the idea of moving towards using Python as the scripting/build
>>> coordinating language, but that might make using non-standard
>>> compliers and/or cross compiling even more difficult.
>>
>> Why?
>
> support non-gnu toolchains. On the other hand, if we're just using
> pure Python, then I agree that it would lend itself to a much cleaner
> build system (though then we risk re-inventing the wheel...)
>
> I don't think requiring (some) Python, and using that to bootstrap the
> build process before building our own Python, is to onerous, though it
> would be funny if the "source Python distribution" had Python as a
> prerequisite.
Even funnier is that Sage *does* have perl as a prerequisite, since
the PARI build system is written in Perl. Nobody mentions or
worries about this, since perl is ubiquitous -- certainly much more
common than "make" or gcc. Before Sphinx, Python's documentation
build system had perl as a prerequisite too.
I would be OK to require "some random python be installed systemwide"
as a prerequisite to build Sage. For windows we require Python...
but if you don't want to install Python we do have a little
"bootstrap" dos script that build's Sage's python.
-- William
>
>> I can only imagine it making things easier since we can structure
>> are code more cleanly and factor out common things. Anyways, one can
>> always do "os.system(...)" so shell capabilities are a subset of
>> Python.
>>
>> This isn't a purely theoretical discussion, since the native Windows
>> porting work of Sage has a Python-based build system already.
>>
>> I'm not arguing for changing anything in the Sage build system right
>> now. I'm just suggesting we should keep an open mind, so when some
>> incredible person shows up at a SAge days (say) who is willing to dive
>> in and do some amazing 1-month coding sprint to improve the build
>> system substantially -- say for a major Sage release like 5.0 -- we
>> are ready.
>
>
> - Robert
>
>
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org