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
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?
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
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.
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
2008/4/10 Gael Varoquaux gael.varoquaux@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,
On Thu, Apr 10, 2008 at 09:23:19PM +0200, Trond Danielsen wrote:
2008/4/10 Gael Varoquaux gael.varoquaux@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
On Thu, Apr 10, 2008 at 11:30 AM, Gael Varoquaux gael.varoquaux@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
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
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
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.
python-devel@lists.fedoraproject.org
-
Gael Varoquaux -
Ignacio Vazquez-Abrams -
Jef Spaleta -
Trond Danielsen