Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
not a single comment... bad... I guess I need to work on the text more if even hardcore Debian people do not feel 'moved' ;-) On Wed, 26 Sep 2012, Yaroslav Halchenko wrote: To not be too ambitious and to not invest too much time I have decided to submit only a talk. Here follows a perspective title, abstract and some notes/outline which will not be a part of submission. I would really appreciate (and of cause would acknowledge in the slides) any feedback, ideas, comments, etc. [originally in emacs org-mode] * Title Debian -- (rich) Python distribution for the bare metal Alternatives: The universal Python distribution or build your own stack Debian Python -- a happy couple with a character Propelling Python to the masses with the universal OS * Abstract Through the years Python community strives to distill the ultimate Python distribution utilities. Meanwhile, to overcome the problems of the core Python and 3rd party FOSS Python projects distribution, various free and commercial distribution bundles of Python appeared. They made Python, as an environment with a pre-selected set of Python modules, conveniently available (primarily) on proprietary systems. What is rarely known is that for decades Python has been a part of the largest in the world software distribution platform: Debian project delivers a complete operating system with thousands of FOSS projects making them available on 11 hardware architectures and 3 different kernels (Linux, HURD, kFreeBSD). In the Linux world, Debian is known as the most popular base distribution due its openness, ease of use, versatility, and stability. By delivering a well integrated and tested versatile OS, with a plethora of core libraries necessary for nearly any field of endeavor, it became an ideal base for the **complete** Python distribution. Majority of Python projects are either already packaged for Debian or provide 1-2 lines instructions on how to install necessary dependencies and build/install the product on Debian-based systems. Recent advances in hardware virtualization support followed in tandem with the explosion of cloud solutions, made Debian systems popular not only among Linux fan-boys but for various, especially scientific and community-driven, deployments. The ease with which thousands of Python-based FOSS became installable and maintainable made Debian the Python distribution with **all** batteries included. In this talk I would like to briefly present the history of Python in Debian (which can be traced to nineties with Python 1.4) and outline benefits Debian provides for Python users and developers, keeping in mind upcoming stable Debian release (wheezy). To familiarize listeners with Python-in-Debian ecosystem I will then overview core package naming, versioning, and modularization conventions in Debian, and briefly present the Debian packaging helper tools, including recent GSOC project aiming to provide automatic packaging of the packages on PyPI. To facilitate the synergy between Python and Debian communities, I will accent on common sense practices (following PEPs, clean and exhaustive legal terms, CI, etc.) which would make any Debian packaging and maintainership more efficient. I am planing to conclude by presenting few easy ways on how to start using Debian. As the outcome of the talk, I expect listeners to become more familiar with the Debian project's standards and principles, become aware of integration aspects involved in delivering such plethora of Python FOSS solutions, and be intrigued enough to try Debian on their systems or in the cloud. Just NOTES: * Python-in-Debian History ** Upstream: Python 1.0 - January 1994, Python 1.5 - December 31, 1997 ** debian-python ML https://lists.debian.org/debian-python/1998/08/msg0.html To: debian-python@lists.debian.org Cc: hoffl...@mathi.uni-heidelberg.de, lore...@argon.roma2.infn.it Subject: Welcome to debian-python From: Hanno Wagner wag...@fitug.de Date: Fri, 7 Aug 1998 09:27:05 +0200 Message-id: 19980807092705.j25...@beuel.rhein.de Reply-to: Hanno Wagner wag...@fitug.de Good morning gentlemen, this is the initial posting for debian-python, the mailinglist is running now. Here is the description for the mailinglist: debian-python@lists.debian.org Description : Discussion of issues related to Python on Debian systems with an stress on packaging standards. Therefore relevant for maintainers of Python related packages. Moderated : no Subscription: open Have a nice start, Ciao, Hanno, one of listmas...@lists.debian.org -- | Hanno Wagner | Member of the HTML Writers Guild | Rince@IRC | | Eine gewerbliche Nutzung meiner Email-Adressen ist nicht gestattet! | | 74 a3 53 cc 0b 19 - we did it! |Generation @ | #Fachbegriffe der Informatik einfach erklaert, Teil 69: #It is
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
On Thu, Sep 27, 2012 at 08:51:37AM -0400, Yaroslav Halchenko wrote: not a single comment... bad... I guess I need to work on the text more if even hardcore Debian people do not feel 'moved' ;-) Well, i'll give my 2c as a pythonista and a Debian-folk On Wed, 26 Sep 2012, Yaroslav Halchenko wrote: To not be too ambitious and to not invest too much time I have decided to submit only a talk. Here follows a perspective title, abstract and some notes/outline which will not be a part of submission. I would really appreciate (and of cause would acknowledge in the slides) any feedback, ideas, comments, etc. [originally in emacs org-mode] * Title Debian -- (rich) Python distribution for the bare metal Alternatives: The universal Python distribution or build your own stack Debian Python -- a happy couple with a character Propelling Python to the masses with the universal OS * Abstract Through the years Python community strives to distill the ultimate Python distribution utilities. Meanwhile, to overcome the problems of the core Python and 3rd party FOSS Python projects distribution, various free and commercial distribution bundles of Python appeared. They made Python, as an environment with a pre-selected set of Python modules, conveniently available (primarily) on proprietary systems. What is rarely known is that for decades Python has been a part of the largest in the world software distribution platform: Debian project delivers a complete operating system with thousands of FOSS projects making them available on 11 hardware architectures and 3 different kernels (Linux, HURD, kFreeBSD). In the Linux world, Debian is known as the most popular base distribution due its openness, ease of use, versatility, and stability. By delivering a well integrated and tested versatile OS, with a plethora of core libraries necessary for nearly any field of endeavor, it became an ideal base for the **complete** Python distribution. Majority of Python projects are either already packaged for Debian or provide 1-2 lines instructions on how to install necessary dependencies and build/install the product on Debian-based systems. Recent advances in hardware virtualization support followed in tandem with the explosion of cloud solutions, made Debian systems popular not only among Linux fan-boys but for various, especially scientific and community-driven, deployments. The ease with which thousands of Python-based FOSS became installable and maintainable made Debian the Python distribution with **all** batteries included. In this talk I would like to briefly present the history of Python in Debian (which can be traced to nineties with Python 1.4) and outline benefits Debian provides for Python users and developers, keeping in mind upcoming stable Debian release (wheezy). To familiarize listeners with Python-in-Debian ecosystem I will then overview core package naming, versioning, and modularization conventions in Debian, I can see this becoming a flamefest. Most hardcore pythonistas (and the types to be at PyCon) refuse to allow apt to install libs globally, and use virtualenv(wrapper) to isolate deps for a few reasons -- the big ones being: - more up to date - isolates dependency hell which (frankly) apt-get / Debian stable can't really address. Sometimes Python packages in sid are out of date as well. 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) :) and briefly present the Debian packaging helper tools, including recent GSOC project aiming to provide automatic packaging of the packages on PyPI. To facilitate the synergy between Python and Debian communities, I will accent on common sense practices (following PEPs, clean and exhaustive legal terms, CI, etc.) which would make any Debian packaging and maintainership more efficient. I am planing to conclude by presenting few easy ways on how to start using Debian. As the outcome of the talk, I expect listeners to become more familiar with the Debian project's standards and principles, become aware of integration aspects involved in delivering such plethora of Python FOSS solutions, and be intrigued enough to try Debian on their systems or in the cloud. Just NOTES: * Python-in-Debian History ** Upstream: Python 1.0 - January 1994, Python 1.5 - December 31, 1997 ** debian-python ML https://lists.debian.org/debian-python/1998/08/msg0.html To: debian-python@lists.debian.org Cc: hoffl...@mathi.uni-heidelberg.de, lore...@argon.roma2.infn.it Subject: Welcome to debian-python From: Hanno Wagner wag...@fitug.de
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
On Thursday 27 September 2012 17:50:04 Paul Tagliamonte wrote: On Thu, Sep 27, 2012 at 08:51:37AM -0400, Yaroslav Halchenko wrote: not a single comment... bad... I guess I need to work on the text more if even hardcore Debian people do not feel 'moved' ;-) Well, i'll give my 2c as a pythonista and a Debian-folk 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 can see this becoming a flamefest. Most hardcore pythonistas (and the types to be at PyCon) refuse to allow apt to install libs globally, and use virtualenv(wrapper) to isolate deps for a few reasons -- the big ones being: - more up to date - isolates dependency hell which (frankly) apt-get / Debian stable can't really address. Sometimes Python packages in sid are out of date as well. 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. I have advocated solutions based on fakechrooted debootstrapped installations 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 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. Paul -- 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/201209272343.21737.p...@boddie.org.uk
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
Thank you Paul, On Thu, 27 Sep 2012, Paul Tagliamonte wrote: I can see this becoming a flamefest. oh no... I hoped to simply present our work and not cause flamefests ;-) Most hardcore pythonistas (and the types to be at PyCon) refuse to allow apt to install libs globally, and use virtualenv(wrapper) to isolate deps for a few reasons -- the big ones being: - more up to date - isolates dependency hell which (frankly) apt-get / Debian stable can't really address. Sometimes Python packages in sid are out of date as well. 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... ? 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 think, as Paul pointed out (reply to his email will follow shortly) that it might be worth to orient the talk more toward the users who per se pretty much need to take care about the whole system -- regular mortals and sysadmins. I'd be happy to help you prepare / do more interactive work with folks at PyCon (I should likely be there) :) Thanks in advance... let's see first if I would be going anywhere ;) -- 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/2012092713.gd26...@onerussian.com
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 -- 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
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
On Friday 28 September 2012 00:23:10 Yaroslav Halchenko wrote: 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. Yes, I had cause to build NumPy from scratch recently, and it was quite intimidating. It did happen to involve a fairly low-performance device with fairly severe memory constraints, and the experience really pushed me towards looking harder at Debian and the packaging work that I knew would have been done to potentially solve some of the issues I was experiencing, one of which being modularisation of the library, although I'm not sure how much this is actually done with NumPy in Debian. 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 I'll try and follow the list and get back to you. 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... ? Having gone through the packaging process, I know that a lot of the hurdles actually do help packagers improve the reliability of the eventual package, even though the process can be drawn out and frustrating. Even non-technical stuff like auditing the licences is a valuable activity, however, that gives users confidence that the end product is of high quality and not just zipped up and uploaded to some site or other. The Python conference scene seems to love testing, so if you can make a case for Debian and quality assurance, and Debian has done things popular with this crowd for years like automated builds and the use of very strict package building tools that won't let you build without a precise specification of the build dependencies, then that may appeal to some people. 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. It's a Python tool for Python developers, primarily. If you're running a Web operation with lots of Python developers and a commitment to Python then it may make sense, but that sort of builds a wall that deters people from adopting Python, too. 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 don't think you should worry too much about flames. My impression is that the packaging people are trying to scale back their ambitions and just get everyone to do the basic things like write decent metadata, mostly because I think the process of delivering a comprehensive solution is deadlocked once again, and I think that people do see the need to hear from distributions and to try and get as much input from them as possible. I have advocated solutions based on fakechrooted
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz - v.2
ok -- here is my next take trying to make at least the title and introduction more user oriented and mention those aspects which might be be of interest for developers... As a result it probably became even less English and now exercises working memory even harder ;) Propelling Python to the masses with the universal OS Python has found appreciation not only among professional developers but also among students, scientists and programming novices due to its scripting nature, batteries included, good collection of 3rd party libraries, and ability to interface to libraries written in other languages and computing environments (e.g. R). To conveniently deliver such a versatile Python platform to users (and their humble system administrators), the community have been distilling the ultimate Python distribution utilities and bundling pre-built Python and core 3rd party libraries and modules for the distribution on proprietary systems. Meanwhile nearly for two decades Python has been a part of the largest community-driven software distribution platform -- Debian. The Debian project delivers a complete operating system with tens of thousands of FOSS projects available on 11 hardware architectures and 3 different kernels (Linux, HURD, kFreeBSD). Being a binary distribution Debian guarantees safer -- free of build-errors -- installations and seamless upgrades. Coupled with the standardized specification of build and run-time dependencies, it made it easy to build, verify, or simply deploy projects of nearly arbitrary complexity of inter-dependencies and varying implementation origins. Such agnosticism to the origins of the software made Python-based products a 1st citizen in this heterogeneous distribution ecosystem, assuring that Python works well with the rest of it. Recent advances in hardware virtualization support, followed in tandem with the explosion of cloud solutions, made Debian systems popular not only among Linux fan-boys but for various, especially scientific and community-driven, deployments. The ease with which thousands of Python-based FOSS became available and maintainable made Debian the Python distribution with **all** batteries (and virtualenv) included. In this talk I would like to briefly present the history of Python in Debian (which can be traced to nineties with Python 1.4), outline benefits Debian provides for Python users/developers and present what to expect in upcoming stable (wheezy) release of Debian. To familiarize listeners with Python-in-Debian ecosystem I will then overview core package naming, versioning, and modularization conventions in Debian and ongoing QA efforts (build-time testing, full-archive rebuilds, etc). I will briefly present the Debian packaging helper tools, including recent GSOC project aiming to provide automatic packaging of the packages on PyPI. To facilitate the synergy between Python and Debian communities, I will accent on common sense practices (following PEPs, clean and exhaustive legal terms, CI, etc.) which would make any Debian packaging and maintainership more efficient and benefit upstream developers. I am planing to conclude by presenting few easy ways on how to start using Debian. As the outcome of the talk, I expect listeners to become more familiar with the Debian project goals, standards and principles, become aware of integration aspects involved in delivering such plethora of Python FOSS solutions, and become intrigued enough to try Debian on their systems or in the cloud. On Fri, 28 Sep 2012, Paul Boddie wrote: On Friday 28 September 2012 00:23:10 Yaroslav Halchenko wrote: 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. Yes, I had cause to build NumPy from scratch recently, and it was quite intimidating. It did happen to involve a fairly low-performance device with fairly severe memory constraints, and the experience really pushed me towards looking harder at Debian and the packaging work that I knew would have been done to potentially solve some of the issues I was experiencing, one of which being modularisation of the library, although I'm not sure how much this is actually done with NumPy in Debian. 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
