Re: Re: Challenges packaging Python for a Linux distro - at Python Language Summit
(apologies i forgot to say, please do cc me, i am using the list archives reply-to links at https://lists.debian.org/debian-python/2021/05/msg00036.html) Thomas Goirand wrote: > All the horrors that you are painting after this paragraph, are due to > the fact that you aren't doing "apt-get dist-upgrade". I'm having a hard > time understanding why you're both: > - not doing "apt-get dist-upgrade" because precisely the difficulties encountered, and due to software development that critically requires more recent variants of what is typically in debian/stable i.e. usually a minimum of one even three years out-of-date. a dist-upgrade to debian / testing - a way to obtain the latest variants of critical software - frequently resulted in massive breakage. i quickly learned never to attempt that again given the massive disruption it caused to me being able to earn money as a software engineer. > - complaining that it's breaking your system ah, you're missing the point by focussing on the background and context. also, i didn't "complain" (despite it causing distress for some considerable number of years), i would have said, "i have a complaint" and stopped at that, rather than moved on to describe the details of what the root cause is. > Could you care to explain? This makes absolutely no sense. i could - but doing so is a distraction. i would prefer to solicit some responses that acknowledge that this is an actual problem that needs solving. Bryan's message unfortunately is a repeat of prior experiences in reporting this issue over the years. > By the way, since you're never doing "apt-get dist-upgrade", it means > your system is full of security issues that aren't getting fixed. > Hopefully, the computer system(s) you're talking about isn't connected > to internet, right? indeed. it's a development laptop on which i am critically reliant for financial income and for furthering free software. Brian May wrote: > A rolling type update might be convenient, but it is not supported by > Debian, and has not been supported by Debian in sometime. There are > complexities in such an arrangement, and it is difficult to test such > arrangements will work as expected. Such an arrangement is not > guaranteed or tested to work. Brian: as an experienced debian systems administrator and python developer I'm not asking for help with either, and over the past 20 years have successfully learned and deployed the techniques required to keep a rolling system operational, in order to keep my business operational and not lose money due to massive downtime either from having to transfer 10 million source code files from laptop to laptop, or from having to perform disaster recovery due to breakage. like Thomas, you are missing the point by focussing on the context and background material rather than focussing on the problem. this was also the tack taken by others when i explained the problem: "it's your own fault, this isn't supported, therefore we don't have to do anything, therefore it's not a bug, therefore the bugreport is summarily dismissed". in my report, if you read it again carefully, i specifically stated that *multiple debian maintainers* are receiving *multiple complaints* of breakage and disruption due to the standard debhelper-python build system not following the "safe" practice outlined by numpy and sci-py. i can only surmise that they probably don't want to say anything because the message being sent to them on summary closure of bugreports is that, well, "nobody cares". what i can say is that they're getting pretty fed up of constantly having to close bugreports, every time someone raises this issue, that's pretty clear from what they didn't say, if you know what i mean. once this is accepted as actually being a problem that needs solving, rather than being avoided because "it's not supported, you're on your own, not our problem", i am happy to help advise and discuss solutions. given that this has been ongoing for 10 years now i have been giving it some thought for a long, long time. however before getting to a discussion of solutions i would prefer to see acknowledgement that it is recognised as a problem that people actively wish to see fixed. otherwise i will have to wait patiently for the next disaster situation to occur, or, sadly, after 20 years of using debian, and remaining loyal to it despite maltreatment, i will have to find an alternative distro. what is stopping me from doing that is the severe financial consequences involved and risk to myself and my family due to my income being far below average. the downtime that would result is a huge risk, plus learning a new distro also compromises my effectiveness which also results in further lost income. what i am saying is: this is serious - i am effectlvely financially trapped and critically dependent on the decisions that you make, even though i am not paying you money for the work that you do. l.
Re: Request to join the Python team
Hi Roland (2021.05.17_16:20:19_+) > So I hereby request to be added to the python-team group on salsa. My > salsa login is "lolando", and I have read and accept the > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > policy. Added, welcome to the team. -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Request to join the Python Team
Hi, I'd like to join the Python team on Salsa. Recently I've taken over the maintainer ship for flask-sqlalchemy together with a long time businesses partner I'm working together with on my day job. And some more packages are to come I want to work on. For another Django based project we needed to get python-django-crispy-forms-foundation packaged. I'm testing currently the prepared Debian packages on this. My username on Salsa is tijuca. Thanks! -- Regards Carsten
Re: Request to join python team
Hi Sérgio (2021.05.11_22:15:20_+) > I would like to join the Debian Python team to help maintain typer and > crochet. > > My Salsa login is sergiosacj. > > I have read > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > and accept it. Added, welcome. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Request to join the Python team
Hi everyone, I've been contracted by Synchrotron Soleil to work on the packaging of Jupyterhub and its dependencies. This turns out to about 20 Python packages, most of which should probably go under the Debian Python Team umbrella (although some may go into Debian Science). So I hereby request to be added to the python-team group on salsa. My salsa login is "lolando", and I have read and accept the https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst policy. Thanks, and see you soon for improving Debian :-) Roland.
Re: request to join the team
Hi Felix (2021.05.14_16:02:53_+) > My salsa login: obfusk > I have read and accepted > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst Welcome, added to the team. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join Debian Python Team
Hi Joseph (2021.05.17_03:26:14_+) > My Salsa username: @njoseph (https://salsa.debian.org/njoseph) > > I hereby declare that I have read the Policy document of the Debian Python > Team at > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > and that I accept it. Added, welcome. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Challenges packaging Python for a Linux distro - at Python Language Summit
Hi Luke, First, I'd like you to know I feel sorry to read how much you seem affected by what you describe below. Hopefully, you'll find a viable solution soon, and hopefully, we may help. However, please try to understand what others are telling. The solution you're looking for is probably not the one you expect, but I'm convince it does exist (ie: venv, probably, or better dependency management). See below. On 5/17/21 8:10 AM, Luke Kenneth Casson Leighton wrote: >> All the horrors that you are painting after this paragraph, are due to >> the fact that you aren't doing "apt-get dist-upgrade". I'm having a hard >> time understanding why you're both: >> - not doing "apt-get dist-upgrade" > > because precisely the difficulties encountered, and due to software > development > that critically requires more recent variants of what is typically in > debian/stable > i.e. usually a minimum of one even three years out-of-date. > > a dist-upgrade to debian / testing - a way to obtain the latest > variants of critical > software - frequently resulted in massive breakage. Massive breakage of what? Your own Python code? Well, it's up to you to stay current to whatever version is in Testing/Unstable. If you don't do it, then it's your responsibility, and you must live with the consequences of it. Yes, it's a massive undertaking to always stay up-to-date, and drains a lot of energy, though no choice if you're serious with what you're doing... > i quickly learned never to attempt that again given the massive disruption > it caused to me being able to earn money as a software engineer. So, to "earn money as a software engineer", you prefer your software to rely on older, probably buggy, and not security supported, dependencies? I'm sorry, but that's far from best practice, and it will bite hard anyways. Yes, dependency management is a hard work. Yes, it takes some of your time (sometimes massively). No, you can't avoid it... >> - complaining that it's breaking your system > > ah, you're missing the point by focussing on the background and context. Are you *SURE* that you're the only person that's right, and that the dozen experienced Debian Developers saying the opposite way are the wrong persons? I would strongly advise you to reconsider. Do you completely understand how "library transitions" are working in Debian? If not, I would strongly advise you to read about it. > i would prefer to solicit some > responses that acknowledge that this is an actual problem that needs > solving. Well, it feels like the only thing you accept, is the answer that *YOU* want, and not the one that others are telling you. Chances that it's going to happen are very thin, since we all know that what you're discussing is not the way Debian works. > Bryan's message unfortunately is a repeat of prior experiences > in reporting this issue over the years. Looks like a lot of people told you the same thing... Do you sometimes listen to what others tell? :) > Brian May wrote: >> A rolling type update might be convenient, but it is not supported by >> Debian, and has not been supported by Debian in sometime. There are >> complexities in such an arrangement, and it is difficult to test such >> arrangements will work as expected. Such an arrangement is not >> guaranteed or tested to work. > > Brian: as an experienced debian systems administrator and python > developer I'm not asking for help with either, and over the past 20 years > have successfully learned and deployed the techniques required to > keep a rolling system operational Apparently, you haven't... > like Thomas, you are missing the point by focussing on the context > and background material rather than focussing on the problem. We aren't at all missing the point that doing the way you're doing is often breaking your system. The problem: you're expecting that never doing "apt-get dist-upgrade" will handle library transitions, when this isn't the way Debian works. We're all telling you, but you do not want to listen, and insist that what you've been doing (wrongly) for 20 years is the correct way of doing things. Sorry, but it's not... You *will* experience breakage, and there's nothing we can do to save you. > this was also the tack taken by others when i explained the problem: > "it's your own fault, this isn't supported, therefore we don't have to > do anything, therefore it's not a bug, therefore the bugreport is > summarily dismissed". Which is 100% correct. > in my report, if you read it again carefully, i specifically stated that > *multiple debian maintainers* are receiving *multiple complaints* of > breakage and disruption due to the standard debhelper-python > build system not following the "safe" practice outlined by > numpy and sci-py. The problem isn't the build system, which is doing things the correct way. Any "arch: any" package linked against Python *must* be upgraded together with the interpreter itself when it transition from Unstable to Testing.
Bug#988658: RFP: python3-pyupgrade -- Automatically upgrade syntax for newer versions of the Python language
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-python@lists.debian.org
* Package name: python3-pyupgrade
Version : 2.16.0
Upstream Author : Anthony Sottile
* URL : https://github.com/asottile/pyupgrade
* License : BSD
Programming Lang: Python
Description : Automatically upgrade syntax for newer versions of the
Python language
This helper script can help you normalize your Python source code
by rewriting parts of your code to use the latest syntax improvements.
Some examples from the README:
set([]) # set()
'{0} {1}'.format(1, 2)# '{} {}'.format(1, 2)
x is 5 # x == 5
'{foo} {bar}'.format(foo=foo, bar=bar) # f'{foo} {bar}'
I discovered this tool by reading some documentation and I'd like
it to be available in Debian so that I can try it and use it :-)
ccing debian-python@lists.debian.org in the hope to catch the attention of
someone with more time than me.
Thank you!
--
Raphaël Hertzog
Re: Re: Challenges packaging Python for a Linux distro - at Python Language Summit
On 2021-05-17 07:10:39 +0100 (+0100), Luke Kenneth Casson Leighton wrote: > (apologies i forgot to say, please do cc me [...] Done. > a dist-upgrade to debian / testing - a way to obtain the latest > variants of critical software - frequently resulted in massive > breakage. > > i quickly learned never to attempt that again given the massive > disruption it caused to me being able to earn money as a software > engineer. [...] You're probably just going to see this as further confirmation of your opinion, or yet another person telling you that you're doing it wrong, but as someone who also writes rather a lot of Python programs for a living I learned long ago to not develop against the "system" on any platform. I use sid/unstable for my development systems, but I consider the python3 package in it to have two uses: Testing new packages of software which are targeting a future Debian stable release, and running other packaged things which are already part of Debian. For software development work, I compile my own Python interpreters and libraries, because I need to develop against a variety of different versions of these, sometimes in chroots, to be able to target other distros and releases thereof. I keep all these in my homedir or otherwise outside of normal system-wide installation paths. Bear in mind that this isn't just a Debian problem, for decades Red Hat has also advised programmers not to rely on their /usr/bin/python for custom development because it is patched and tuned specifically for running system applications packaged for their distro and not intended as a general-purpose Python distribution. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Challenges packaging Python for a Linux distro - at Python Language Summit
On 5/16/21 1:52 PM, Luke Kenneth Casson Leighton wrote: >> * One 3.x version at a time. Doesn't line up with cpython's support terms. > numpy and sci-py, the two "best known" debian python software > packages, have known about this for a long, long, time. they > quietly solved it by adding explicit building of **MULTIPLE** > versions of numpy-3.5, numpy-3.6, numpy-3.7, etc. etc. > i leave you with these insights. there *is* a solution: do what numpy and > sci-py do. I don't understand why you are pointing to numpy and scipy as good examples. The modules are not built in any different way from all the modules shipped in Debian. Matthias
Re: Re: Challenges packaging Python for a Linux distro - at Python Language Summit
Jeremy Stanley writes: > For software development work, I compile my own Python interpreters > and libraries, because I need to develop against a variety of > different versions of these, sometimes in chroots, to be able to > target other distros and releases thereof. I keep all these in my > homedir or otherwise outside of normal system-wide installation > paths. Bear in mind that this isn't just a Debian problem, for > decades Red Hat has also advised programmers not to rely on their > /usr/bin/python for custom development because it is patched and > tuned specifically for running system applications packaged for > their distro and not intended as a general-purpose Python > distribution. There are tools that will help you do this. e.g. pyenv, asdf, etc. But, yes, for my own software development, I gave up trying to use Debian python packages years ago, because I found I was spending way more time trying to package the required dependencies (and dependencies of dependencies of dependencies) then I spending developing my application. This gets even worse if you want to support rpm based distributions. Plus the fact that I was becoming increasingly concerned that if I upgraded library python3-L for application A, I might accidentally break applications B, C, and D also, and testing/fixing everything at the same time not really feasible. So now I use asdf + poetry/virtualenvs now, plus Docker for distribution. As a result, I can upgrade the dependencies in each application one application at a time. If an application breaks, I just need to fix that one application, without breaking everything else at the same time. I can upgrade the OS distribution, and not be concerned (mostly anyway) that it will break my applications in weird and wonderful ways that I could not predict. This isn't so useful for distribution of Python based desktop applications, but I don't do a lot of that (and probably would be looking for a good off-the-shelf solution if I did). -- Brian May
Bug#988691: RFP: python-comment-parser -- extract comments from source code (Python)
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org, vagr...@debian.org * Package name: python-comment-parser Version : 1.2.3 Upstream Author : Jean-Ralph Aviles * URL or Web page : https://github.com/jeanralphaviles/comment_parser * License : Expat Description : extract comments from source code (Python) This Python module can be used to extract comments from source code in various languages. Supported languages include: C, C++/C#, Go, HTML, Java, Javascript, Python, Ruby, Shell, and XML. I've made a quick packaging attempt that will soon be available at: https://salsa.debian.org/vagrant/python-comment-parser I do not have a lot of experience packaging python modules, so if someone with more experience and enthusiam for python packaging would like to take this on, that would be great, as I don't forsee uploading this to Debian myself; I'm packaging this for my own use at the moment, but if I need to use it more maybe I'll take a more active interest... live well, vagrant signature.asc Description: PGP signature
