[Neurodebian-upstream] PyNN + NeuroTools packages

[Yaroslav Halchenko]

On Sun, 14 Nov 2010, Yury V. Zaytsev wrote:
> > Great to have James Haxby's support for all our "silly" endeavors ;)
> Could you please send one copy of James Haxby my way? ;-)

Here is a doctestable script for that:
>>> from copy import deepcopy
>>> haxby2 = deepcopy('haxby')
;-)


> I am not sure how you envision your ND branded distribution, but if I
> ever had more time, I would go for writing a UCK [1] script and if time
> permits, making a separate package for branding. 

> This way you can rebuild your LiveCD regularly to include latest updates
> >...<
> Also unless it's all packaged, I would go for keeping customizations to

;-) of cause we value our time, so everything should be as automated as
possible.

For reference: for NeuroDebian virtual machine, we already have
nearly everything automated, including pre-seeding of the
debian-installer, and customizations are provided by neurodebian-*
packages.  Everything necessary is available from our neurodebian source
package repository:

http://git.debian.org/?p=pkg-exppsy/neurodebian.git

For live-cd which we once approached, there is tools/makelivecd.sh which
uses live-build (Debian Live) creator.  I guess we should come back to
that script... thanks for UCK pointer -- I will check it out, may be
there is something it could inspire on top what we already have
available ;)

> On the other hand, it's easily possible to throw in extra NeuroDebian
> sources in the sources.d upon installation if you have it packaged as
> neurodebian-desktop for instance 
yeap -- we have that one already for actually 'branding' the user
desktop

> and trigger the installation of the
> same set of packages you have on the LiveCD.
well, if we aimed at a single Live NeuroDebian something, it must be a
DVD I guess since CD would not be large enough to provide a good
coverage of NeuroDebian software.  Or we could provide a collection of
themed live CDs (NeuroImaging, NeuralSimulators, etc), but I am not sure
if it is worth it, since everyone probably has DVDs these days.

> Are you aware of the existence of the INCF LiveCD [2] by the way?
Nope... and how could I -- there seems to be nothing to download from
that page: "This tool currently has no files for download. "

What we discovered recently is a Lin4Neuro live "distribution":

http://www.nemotos.net/?page_id=286

based on ubuntu 10.04 + our backports provided from neuro.debian
repository + few tools manually installed under /usr/local .

> project already has some traction and money you can somehow negotiate
> with them to transfer you all they have so far and name it the official
> successor of the INCF thing (which will bring you more users)...

it remains to discover what they have ;)
Since INCF is at SfN now as well, may be we will stop by at their booth
to discuss this matter (if there would be any relevant person here)

> > packaging (no unittesting during build etc) is trivial especially with
> > debhelper7
> Unfortunately, most of the packages you would want to get done are not
> exactly properly packaged trivial pure-Python distutils/setuptools
> scripts :-/ 
hm, which one do you have in mind?  e.g. Brian was quite ok ;-)

> I think Debian wiki definitively needs updating with recipes and a set
> of exemplar packages utilizing each of the currently used packaging
> helpers (python-support, python-central, dh_python2 etc.)
-central is deprecated afaik

> Also, everything that is discussed on IRC / mailing list is reflected in
> the policy with a huge lag. Take for instance the recent discussions on
> XS-P-V / XB-P-V / X-P-V. It took me a lot of reading and bugging people
> on IRC to find out what is the common wisdom on this topic at the
> moment.
I must agree that it is all confusing and not clear.  That is why I am
trying to follow a minimalistic way:  e.g. I am trying to make sure that
module is compatible with all supported python versions and simply
ignore those X*-P-V fields altogether ;) as I said, Python policy is
just a guideline ;-)

> This is a well-known issue and I am not quite sure if it will get solved
> in the near future (I certainly do hope so, but...). The major problem
> is that corporate contributors want to control the distribution and
> limit the use of the technology by the competitors.
and I am not sure if I want to be controlled by corporations in my
research (unless I am employed by the corporation so it would be in
their interests to keep me effective, which is not the case obviously).

> On the other hand, this licence doesn't prevent me from packaging it for
> my own use and releasing my package under MIT, so if for instance
> someone wants a cluster deployment they don't have to go through the
> same pain. And of course, I do have an agreement with myself :-)
I am still not sure how you are not violating their license.... where
could I checkout your MIT-licensed packages which do not distribute any
NEST code?  Are they downloader/installer packages (e.g. like I have
done for MIPAV)?

> However, there is another beacon of hope floating around, that is that
> NEST initiative can officially set up an apt repository in the same
> controlled manner, but at least, users will get updates automatically
> and won't need to compile themselves, which is not trivial in all cases.
> Obviously, the rules of NEST initiative do not apply to the initiative
> itself ;-)
well... I can only wish them good luck I guess ;-)

> P.S. Could you please set the lists in a way so that they don't send out
> duplicates when they see a subscriber in the list of direct recipients?
> I remember it was somewhere in the mailman options...
will do whenever get a moment, thanks

-- 
                                  .-.
=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]