Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
Thank you Paul ;-)
Good comments -- once again, arguments seems to be oriented mostly
toward developers... I guess I should explicitly guide the
abstract more toward 'user-' and "sysadmin-" use cases: people
in need to have easy and uniform paths for software installation and
maintenance of the heterogeneous system. In scientific users domain it
becomes even more fun with heavier reliance on computational and I/O
libraries (blas/atlas, hdf5, etc) building and maintaining which might
be quite a bit of a hassle.
Few inline comments.
> I was going to give some feedback more as the kind of person who has gone to
> Python conferences, and certainly, if you want a native speaker to give
> feedback on the phrasing of your proposal, I'd be happy to make some
> suggestions.
I would appreciate "native speaker" feedback! since "accepting all
types of proposals through September 28, 2012", I guess I have the whole
tomorrow to revise and submit. I hope to find some time later today to
revise my abstract and will post it again for further phrasing
suggestions
That is true... Somewhat offtopic -- that is why with neuro.debian.net
we pretty much serve an unofficial backports repository for a good
portion of Python modules we maintain. Besides immediate benefit for
users, benefit from backporting for developers has been build-time
testing across various releases of Debians and Ubuntus, picking out
problems with specific versions of the core libraries... So, may be I
should add an accent that availability in Debian doesn't only guarantee
ease of installation (for users) but provides a good test bed for the
developers to preclude problems with future deployments on Debian-based
platforms... ?
> Python packaging has become somewhat insular over the years with
> Python-centric solutions that work across different systems rather than
> solutions that work well with the rest of the software on particular systems.
> However, people appear to like things like virtualenv, especially the Web
> crowd that makes up a lot of the audience at events like this, because it
> lets them set up relatively cheap configurations for separate Web
> applications or for experimenting.
virtualenv is indeed great for the reasons you guys point out AND
indeed, it is very Python-centric and maintenance of a configured
virtualenv might become cumbersome for projects with lots of 3rd party
dependencies and for regular users who would not want to care to switch
among different virtualenvs etc.
I guess I should revise abstract to aim a listener wondering "why should
I care about Debian if there is virtualenv" WITHOUT explicitly pointing
to its pros to not cause any flames. And not sure I would be able to
convince hard-core Python-ians, so I might not even try and orient
it more toward users/admins.
> I have advocated solutions based on fakechrooted debootstrapped installations
btw -- how is it working out for you? i.e. are you still pushing it
forward?
> if only because you can manage the libraries below the Python modules and
> extensions as well as the stuff that supports things like distutils and
> setuptools. However, the people who can change this situation don't see the
> need or the point: it's either "but I have root!" or "they can always build
many (users on managed boxes) -- don't, so I would have pushed these
approaches for them as well ;)
> from source!" No wonder people use stuff like virtualenv instead. It is in
> this area where I feel that the Debian community could do more to meet others
> half-way.
> > People don't care about API stability or anything like that, so I think
> > you might have to try to frame this in a way that doesn't provoke a
> > virtualenv-vs-apt battle -- because, frankly, neither side will win and
> > it'll just become a bit murky.
> > I'd be happy to help you prepare / do more interactive work with folks
> > at PyCon (I should likely be there) :)
> The one case that many language-focused groups ignore, and where distributions
> do well, is the case where a range of different technologies needs to be
> managed and where administrators just wouldn't be able to keep up with Python
> eggs, Ruby gems, CPAN, and the language-specific technology of the week.
> Persuading the Python community to feed packages into Debian so that they
> become a safer choice for people who routinely use or know other technologies
> is definitely a worthwhile cause.
indeed safer and more accessible choice.
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
Reply to: