Path: csiph.com!pasdenom.info!weretis.net!feeder8.news.weretis.net!fu-berlin.de!bofh.it!news.nic.it!robomod From: Salvo Tomaselli Newsgroups: linux.debian.maint.python Subject: Re: python devs complaining about debian packaging Date: Mon, 03 Jun 2024 21:10:02 +0200 Message-ID: References: X-Original-To: Paul Boddie X-Mailbox-Line: From debian-python-request@lists.debian.org Mon Jun 3 19:07:46 2024 Old-Return-Path: X-Amavis-Spam-Status: No, score=-7.56 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, FOURLA=0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, LDO_WHITELIST=-5, MD5_SHA1_SUM=-1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no X-Policyd-Weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 CL_IP_EQ_HELO_IP=-2 (check from: .gmail. - helo: .mail-wr1-f53.google. - helo-domain: .google.) FROM/MX_MATCHES_HELO(DOMAIN)=-2; rate: -5.5 X-Forwarded-Encrypted: i=1; AJvYcCX/JF8BafQ7FSR0WXDlXQLjhpnaove6sjxBS8BCXGO6fx3gN8li/yxdHu8pcWQ+VyjoLvaSPb6d9PJYQ+yOk4FIomwSSTpzNeeH9v4OvWo= X-Gm-Message-State: AOJu0YxQJ9LXgESUrPpMFB0zuznGv2U4drghRg0lAkqYYzFczog83PWK iS4pUWNEkzA4zU3yx8lnwg+U0JTH7euP53zMVSuzBtWcwNMaiyt/A9jBVTqoD7Dwxtg3bC5jGcY P1QG7PKh7dCPszR7BRvuo2Lj+q2c= X-Google-SMTP-Source: AGHT+IG7Nwzr7B3zvFRrQEvLT8F4D6zj1EvVaB5EJ7u6FXz+89xJ/Tx8LDK7tW8N+VLK1Wc17a+eTYwVkq0O5p+ROAA= X-Received: by 2002:adf:ef42:0:b0:354:df32:69da with SMTP id ffacd0b85a97d-35e7c541d04mr528692f8f.14.1717441648016; Mon, 03 Jun 2024 12:07:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailing-List: archive/latest/21925 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/CAOOnQAefxBN2r6Rth7=VH7dv+hR6rooE9VM-gSNjKE=17vn4eg@mail.gmail.com Approved: robomod@news.nic.it Lines: 97 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: Salvo Tomaselli , Donald Stufft , debian-python@lists.debian.org X-Original-Date: Mon, 3 Jun 2024 21:07:15 +0200 X-Original-Message-ID: X-Original-References: <2901031.mvXUDI8C0e@galatea> <1769026.OF5ZDIzWm4@jason> Xref: csiph.com linux.debian.maint.python:15894 I remember doing this pull request over a decade ago: https://github.com/broadinstitute/xtermcolor/pull/12/files#diff-60f61ab7a8d= 1910d86d9fda2261620314edcae5894d5aaa236b821c7256badd7 to a project that used setuptools + something to download setuptools to be able to use it. I fail to see how that was in any way better than just using what was in the stdlib. Setuptools has always been a weird thing to possibly get rid of=E2=80=A6 an= d why have 485 lines of completely unmaintained script to download setuptools when distutils would do? Well I think the author just followed some tutorial or guide at that time. But it was problematic from the beginning that setuptools emerged. And now things are even worse. Even if my post with the link to xkcd got removed from the python discuss, the situation remains the same, with new things to do the same thing being invented all the time. Il giorno lun 3 giu 2024 alle ore 17:57 Paul Boddie ha scritto: > > On Monday, 3 June 2024 16:27:29 CEST Donald Stufft wrote: > > > > In the interim the packaging toolchain evolved to the point that having > > distutils in the stdlib was no longer of general benefit, and in fact m= ade > > things worse because people had grown accustomed to things like `from > > distutils import setup` being transparently monkeypatched to be setupto= ols > > under the covers. > > The way that distutils could not be relied upon to behave in a sensible w= ay is > entirely the fault of the developer(s) of setuptools having free rein to > corrupt the Python packaging stack. In environments where I wanted to ins= tall > to a particular location only the software I had already acquired, which = is > largely what the deployment element involved in distribution packaging ca= n be > reduced to, I did not want to be dealing with setuptools when distutils w= ould > do, nor with random hacks introduced to make distutils behave like setupt= ools. > > For a while, I routinely stripped out unnecessary setuptools references f= rom > setup.py files, put distutils support back in, and mostly got the desired > effect. But in the Python world, once someone teases some fancy new featu= res > and they catch on, everybody else has to hold on for the wild ride and bu= dget > for the consequences. > > (For some software I have been trying to package, I see now that there is= no > setup.py or anything else, with some more "magic" introduced to be proces= sed > by yet another tool. I apparently have to get with it, or something to th= at > effect, which severely diminishes my interest in packaging that software = at > all. The outcome actually affects the Debian project directly, not that v= ery > many people seem to care, however.) > > I suppose it also didn't help that distutils entered the standard library= in > the era where it was apparently acceptable to get one's code included and= to > then declare the job done. Back when Python 3 was initially introduced, I > suggested that the standard library be reviewed and fixed up, especially = since > there was going to be a compatibility break anyway, but there was no appe= tite > for it. > > Still, I appreciate you engaging with this forum, even if it probably mea= ns > having to defend decisions made by others. > > Paul > > --=20 Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io