twisted spkg
jason...@creativetrax.com
We don't apply any customizations to twisted anymore; we just install it
straight as a python package. I think it would be easier to just
include it in the sagenb spkg as a dependency (like flask, etc.). That
would mean that we automatically get the latest twisted every time the
sagenb spkg is updated, instead of having to maintain a separate twisted
spkg. Does anyone have any objections to removing the twisted spkg and
including twisted into the sagenb spkg?
Please vote:
[ ] Yes, remove the twisted spkg and include twisted in the sagenb spkg
as a dependency
[ ] No, keep the twisted spkg as a separate spkg
Thanks,
Jason
François Bissey
is pretty much independent of the rest of sage and twisted is only used in the
notebook as far as I know.
So:
If twisted is only used by the notebook include it in sagenb, make its
maintenance the sole responsibility of sagenb. Otherwise keep it separate.
Mind you that including twisted in sagenb will hurt in sage-on-gentoo because
if we use the spkg to distribute it we will waste bandwith since we use
twisted provided by the system.
Francois
Jason Grout
> On Mon, 16 Jan 2012 16:36:50 jason...@creativetrax.com wrote:
>> Hi everyone,
>>
>> We don't apply any customizations to twisted anymore; we just install it
>> straight as a python package. I think it would be easier to just
>> include it in the sagenb spkg as a dependency (like flask, etc.). That
>> would mean that we automatically get the latest twisted every time the
>> sagenb spkg is updated, instead of having to maintain a separate twisted
>> spkg. Does anyone have any objections to removing the twisted spkg and
>> including twisted into the sagenb spkg?
>>
>> Please vote:
>>
>> [ ] Yes, remove the twisted spkg and include twisted in the sagenb spkg
>> as a dependency
>>
>> [ ] No, keep the twisted spkg as a separate spkg
>>
> I generally not in favor of spkg inside other spkg. On the other hands sagenb
> is pretty much independent of the rest of sage and twisted is only used in the
> notebook as far as I know.
twisted won't be a full spkg inside of an spkg. Already, the sagenb
spkg includes a number of dependencies, and twisted would just be added
to those (like flask, various flask extensions, pytz, etc.)
It would be trivial to make a "bare" sagenb spkg that doesn't include
any dependencies, but relies on them being installed already (or
downloads them from the internet on-the-fly).
> So:
> If twisted is only used by the notebook include it in sagenb, make its
> maintenance the sole responsibility of sagenb. Otherwise keep it separate.
Yes, this would be mean that twisted is the sole responsibility of the
sagenb project.
>
> Mind you that including twisted in sagenb will hurt in sage-on-gentoo because
> if we use the spkg to distribute it we will waste bandwith since we use
> twisted provided by the system.
Would the above "bare" spkg help you? At one point, we also had two
spkgs---sagenb and sagenb-dependencies. Would you vote returning to
that two-spkg model?
Thanks,
Jason
François Bissey
Francois
Jason Grout
Making a sagenb spkg and an optional bare sagenb spkg would actually be
easier to set up, and I presume no loss for you guys, right?
So I count 2 yes votes (including mine) to eliminating the twisted spkg.
Does anyone else have an opinion?
Thanks,
Jason
François Bissey
Francois
Keshav Kini
-Keshav
----
Join us in #sagemath on irc.freenode.net !
Dima Pasechnik
as a dependency.
On Tuesday, 17 January 2012 06:36:50 UTC+8, jason wrote:
Hi everyone,We don't apply any customizations to twisted anymore; we just install it
straight as a python package. I think it would be easier to just
include it in the sagenb spkg as a dependency (like flask, etc.). That
would mean that we automatically get the latest twisted every time the
sagenb spkg is updated, instead of having to maintain a separate twisted
spkg. Does anyone have any objections to removing the twisted spkg and
including twisted into the sagenb spkg?Please vote:
[X ] Yes, remove the twisted spkg and include twisted in the sagenb spkg
as a dependency
Julien Puydt
I vote for anything which makes it easier to use system-installed
components instead of having yet another version of them!
Snark on #sagemath
Jeroen Demeyer
> Please vote:
>
> [ ] Yes, remove the twisted spkg and include twisted in the sagenb spkg
> as a dependency
>
I dislike putting everything into one big spkg. Having some separation
looks cleaner to me. What if we *do* need to patch Twisted in the
future, what's the procedure for that?
Jason Grout
We can include the patch in the sagenb spkg, in a patches directory,
that is then applied to the twisted source there.
If we separate out twisted on principle, it seems like we should
separate out the other 13 dependent packages that are included. That's
a maintenance burden I can't take on right now.
Thanks,
Jason
Julien Puydt
> If we separate out twisted on principle, it seems like we should
> separate out the other 13 dependent packages that are included. That's a
> maintenance burden I can't take on right now.
Are those heavily patched with respect to upstream?
Snark on #sagemath
Jason Grout
None, including twisted, are patched with respect to upstream.
Jason
Julien Puydt
Why is there a maintenance burden for pieces of code which upstream
takes full care of?
Snark on #sagemath
Jason Grout
The maintenance burden is in making and releasing a new spkg for every
single upstream update if we split those off into separate spkgs,
compared to the sagenb spkg automatically downloading and including
necessary dependencies in itself.
Thanks,
Jason
Julien Puydt
This is something I have noticed : on the other hand, having spkg means
that to share some experimental code with inexperienced people, it's
just a single file to transmit, and it will mostly just work. This is
good, and must stay!
On the other hand, that means that each spkg is its own repository,
which is quite a pain during development. For example, sage may have
foo-3.14.p3, and on some bug report, someone comes up with foo-3.14.p4
with a patch (and must hence share the whole big archive instead of the
one-liner patch) ; and on another bug report, someone else has a
foo-3.14.p4 with another patch (same problem). This also implies that
when a new upstream comes, a new spkg must be made, which isn't that
trivial. A maintenance pain, as you put it.
Does it really make sense to have the shipped (both mandatory and
optional) parts of sage as spkg? Spkg is nice for optional *and*
external stuff, why would it make sense for the "base" install?
Wouldn't it be better to have sage structured like this somewhere (just
the inspiration of the moment, don't take this as a polished and perfect
design document) :
sage/
mandatory/
upstream/
foo-3.14.tar.bz2
bar-20120115.tar.bz2
...
foo/
patches/
build-script
bar/
patches/
build-script
...
optional/ (but shipped with sage)
upstream/
...
whatever/
...
...
spkg/
(the necessary things to list, download& install spkg)
where the tarballs in the upstream directories are the upstream
*unmodified* archives.
The advantages would be :
- everything is under the same revision control tree (no more one
repository by package [and worse, a tar+bzip2-ed repository!]) ;
- just share patches of a few bytes instead of several megs ;
- it's easy to see if sage has specific patches for something or not ;
- updating a package can be as simple as dropping the new upstream
tarball, remove the old and change the version number in the
corresponding build-script (one-liner).
- it's easier to share in-progress work within the community : just get
the repository, and you'll know what is 4.8.alpha1 [it's tagged], you'll
even see the changes of the day by the maintainers ;
Just some thoughts,
Snark on #sagemath
Keshav Kini
Isn't this basically what sage-on-gentoo is doing right now? In fact,
they take it even further - patches and setup scripts for ALL packages
are in the same repository, and upstream sources for ALL packages are
downloaded at build time. See http://github.com/cschwan/sage-on-gentoo
.
Burcin's lmonade ( http://lmona.de/ ) is doing something similar, but
with Gentoo Prefix instead of Gentoo (so that you can run it on other
distros). And it looks like the focus of lmonade is broader than Sage,
by the way (just guessing from what I see on the website). Personally
I think this kind of approach (sage-on-gentoo / gentoo prefix) is
ideal for distributing Sage. We shouldn't need SPKGs at all. All the
setup scripts being under one repository is a much better idea, as you
said.
Jason Grout
>
> Burcin's lmonade ( http://lmona.de/ ) is doing something similar, but
> with Gentoo Prefix instead of Gentoo (so that you can run it on other
> distros). And it looks like the focus of lmonade is broader than Sage,
> by the way (just guessing from what I see on the website). Personally
> I think this kind of approach (sage-on-gentoo / gentoo prefix) is
> ideal for distributing Sage. We shouldn't need SPKGs at all. All the
> setup scripts being under one repository is a much better idea, as you
> said.
This also sounds somewhat similar to Homebrew:
http://mxcl.github.com/homebrew/
Jason
François Bissey
a prefix) or lmonade is in the future. We need to get it running properly
first. The present is the fate of the twisted spkg.
A discussion on alternative building strategy for sage is nice but should
really belong to another thread. For now, you are welcome to try it
and tell us what's wrong with it in your opinion. There is definitely
scope to talk about on sage-devel but in its own thread.
Francois
Jason Grout
> Let's not get out of focus here. Switching to stuff like sage-on-gentoo (on
> a prefix) or lmonade is in the future. We need to get it running properly
> first. The present is the fate of the twisted spkg.
Thanks for bringing us back around. We've posted the necessary patch on
http://trac.sagemath.org/sage_trac/ticket/11874 and updated the sagenb
spkg at http://trac.sagemath.org/sage_trac/ticket/11080 to include twisted.
So #11874 just needs review.
Thanks,
Jason