9:53 a.m.
Hi,
I am the guy who asked about packaging mayavi2 a few weeks ago.
Unfortunately I didn't realize the discussion was going on on the ML with
me following.
To pick up on the points that have been raised on the ML:
I agree that packaging the whole Enthought Tool Suite would be very nice,
and much better than shipping it in a coarse-grained set of packages, as
Debian and Ubuntu have been doing. Making 15 or so packages is more work
than making 4, but it is more value.
I, and probably Dave Perterson and many other on the enthought-dev
mailing list (https://mail.enthought.com/mailman/listinfo/enthought-dev )
would be very happy to help you in this endeavour by answering any
question you have about the ETS. I do not have any experience with RPM
packaging, and do not have access to a fedora box to test, but I can try
to help with as much as I can by providing upstream knowledge and fixing
small problems upstream, if any.
I am now subscribed to this mailing list (god, another mailing list in my
already cramed mailbox, how will I ever get some work done!). Keep me
posted. I want to stress that if you don't have the time to package all
the ETS with all the different packages, a set of 4 packages is what we
settled for Debian to distribute the whole suite. Better this than no
packages, and the modularity can come later.
Keep me posted.
Cheers,
Gaël
10:32 a.m.
On Thu, 2008-04-10 at 16:53 +0200, Gael Varoquaux wrote:
I agree that packaging the whole Enthought Tool Suite would be very
nice,
and much better than shipping it in a coarse-grained set of packages, as
Debian and Ubuntu have been doing. Making 15 or so packages is more work
than making 4, but it is more value.
Is there a dependency tree/graph anywhere we can look at to decide which
pieces to tackle first?
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
10:52 a.m.
On Thu, Apr 10, 2008 at 11:32:07AM -0400, Ignacio Vazquez-Abrams wrote:
On Thu, 2008-04-10 at 16:53 +0200, Gael Varoquaux wrote:
> I agree that packaging the whole Enthought Tool Suite would be very nice,
> and much better than shipping it in a coarse-grained set of packages, as
> Debian and Ubuntu have been doing. Making 15 or so packages is more work
> than making 4, but it is more value.
Is there a dependency tree/graph anywhere we can look at to decide
which
pieces to tackle first?
We are using setuptools to declare dependencies. I don't see an obious
way of generating a dependency graph from setuptools. We also have all
the interproject dependencies listed in
https://svn.enthought.com/enthought/browser/project_map.ini, using a
home-made dependency-inspection tool.
I am having a look at seeing how this tool can be used to generate such
graph. I will post the result on the list (don't hold your breath, I am
also working on some day work).
Cheers,
Gaël
11:11 a.m.
On Thu, 2008-04-10 at 17:52 +0200, Gael Varoquaux wrote:
On Thu, Apr 10, 2008 at 11:32:07AM -0400, Ignacio Vazquez-Abrams
wrote:
> On Thu, 2008-04-10 at 16:53 +0200, Gael Varoquaux wrote:
> > I agree that packaging the whole Enthought Tool Suite would be very nice,
> > and much better than shipping it in a coarse-grained set of packages, as
> > Debian and Ubuntu have been doing. Making 15 or so packages is more work
> > than making 4, but it is more value.
> Is there a dependency tree/graph anywhere we can look at to decide which
> pieces to tackle first?
We are using setuptools to declare dependencies. I don't see an obious
way of generating a dependency graph from setuptools. We also have all
the interproject dependencies listed in
https://svn.enthought.com/enthought/browser/project_map.ini, using a
home-made dependency-inspection tool.
I am having a look at seeing how this tool can be used to generate such
graph. I will post the result on the list (don't hold your breath, I am
also working on some day work).
Well, we don't need a graph per se; I think that file should be enough,
thanks.
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
11:14 a.m.
On Thu, Apr 10, 2008 at 12:11:14PM -0400, Ignacio Vazquez-Abrams wrote:
Well, we don't need a graph per se; I think that file should be
enough,
thanks.
As you wish. I think I will have a go at the graph thing (I have already
started) because it is useful anyhow.
For packaging, you are only interested in the closure of ets_2.7.1, which
is the latest released version.
This reduces the graph a lot :->.
Cheers,
Gaël
2:23 p.m.
2008/4/10 Gael Varoquaux <gael.varoquaux(a)normalesup.org>:
For packaging, you are only interested in the closure of ets_2.7.1,
which
is the latest released version.
Just one quick question: Are there tarballs available for the various
enthought components, or do we have to pull every single one from svn?
I looked at the enthought wiki, but I could not find anything there.
Regards,
--
Trond Danielsen
2:30 p.m.
On Thu, Apr 10, 2008 at 09:23:19PM +0200, Trond Danielsen wrote:
2008/4/10 Gael Varoquaux <gael.varoquaux(a)normalesup.org>:
> For packaging, you are only interested in the closure of ets_2.7.1, which
> is the latest released version.
Just one quick question: Are there tarballs available for the
various
enthought components, or do we have to pull every single one from svn?
I looked at the enthought wiki, but I could not find anything there.
Our wiki is horrible. We are in the process of reworking it, but nobody
agrees on how it should be done.
The tarballs of each released packages are located on
http://code.enthought.com/enstaller/eggs/source/
You do need a dependency graph to be able to make some sense of this. I
am making good progress on making a nice one.
Cheers,
Gaël
4:43 p.m.
On Thu, Apr 10, 2008 at 11:30 AM, Gael Varoquaux
<gael.varoquaux(a)normalesup.org> wrote:
Our wiki is horrible. We are in the process of reworking it, but
nobody
agrees on how it should be done.
This is easy to fix. Have everyone agree on the one person who has
the authority to decide what to implement..and then everyone sucks it
up and lives with that person's decision.
The tarballs of each released packages are located on
http://code.enthought.com/enstaller/eggs/source/
You do need a dependency graph to be able to make some sense of this. I
am making good progress on making a nice one.
Just for clarification... the eggs are completely source...and don't
contain binary blobs of any sort?
-jef
4:49 p.m.
On Thu, Apr 10, 2008 at 01:43:34PM -0800, Jeff Spaleta wrote:
> The tarballs of each released packages are located on
> You do need a dependency graph to be able to make some sense of
this. I
> am making good progress on making a nice one.
Just for clarification... the eggs are completely source...and
don't
contain binary blobs of any sort?
Yes. I am not an Enthought employee. I have no financial interest or
other interest than promoting high-quality open-source scientific
packages. I am very much attached to the open source values. I have made
sure, together with the Debian packagers, that the ETS was Debian Free
Software Guidelines compatible (even if I don't agree with all what's in
there).
All the code is licensed under BDS 3 clause (no advertizing clause). The
license of some of the icons vary, and is mentionned in the
"icon_license.txt" file for each project. However everything is licensed
under non-copyleft licenses (LGPL, Eclipse, ...).
I hope this clarifies things. If there are any more questions, please do
not hesitate.
Cheers,
Gaël
5:24 p.m.
On Thu, Apr 10, 2008 at 06:14:03PM +0200, Gael Varoquaux wrote:
On Thu, Apr 10, 2008 at 12:11:14PM -0400, Ignacio Vazquez-Abrams
wrote:
> Well, we don't need a graph per se; I think that file should be enough,
> thanks.
As you wish. I think I will have a go at the graph thing (I have
already
started) because it is useful anyhow.
For people in a hurry, I just put a first graph on the net, on
http://gael-varoquaux.info/ets_deps.png
It will not stay there, I am just working in making the code that
generates this a bit more reliable, and will publish this on the
Enthought wiki.
The graph is quite horrendous. I had never seen it before, but from
inside it did look bad. Now the good news is that for version 3 of the
ETS, the graph looks like:
http://gael-varoquaux.info/ets3_deps.png
Way better.
I hope this helps a bit having a better understanding of the packaging.
Maybe an interesting way of doing a coarse-grained approach, is to group
packages as they are reorganized in ETS3. You can have a look at the
organisation on the svn repo: https://svn.enthought.com/enthought/browser
Look in the "trunk" folder of each project.
Cheers,
Gaël
1:31 p.m.
On Thu, Apr 10, 2008 at 11:32:07AM -0400, Ignacio Vazquez-Abrams wrote:
On Thu, 2008-04-10 at 16:53 +0200, Gael Varoquaux wrote:
> I agree that packaging the whole Enthought Tool Suite would be very nice,
> and much better than shipping it in a coarse-grained set of packages, as
> Debian and Ubuntu have been doing. Making 15 or so packages is more work
> than making 4, but it is more value.
Is there a dependency tree/graph anywhere we can look at to decide
which
pieces to tackle first?
By the way, what can we do, what tools and information can we provide to
make your work easier?
Specificaly, what is your workflow to package a suite of tools with cross
dependencies like the ETS, relying heavily on setuptools? We are having a
internal discussion on how to make it as easy as possible to package ETS
and maintain for downstream, and as none of us has much packaging
experience it would be great to have as much feedback as possible.
5856
days inactive
5857
days old
python-devel@lists.fedoraproject.org
10 comments
4 participants
participants (4)
-
Gael Varoquaux -
Ignacio Vazquez-Abrams -
Jef Spaleta -
Trond Danielsen