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 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120927222310.gj5...@onerussian.com