Date: Sat, 02 May 2026 00:15:59 +0000 From: bugzilla-noreply@freebsd.org To: python@FreeBSD.org Subject: [Bug 294631] devel/py-installer: use os.path.abspath() instead of Path.resolve() Message-ID: <bug-294631-21822-HeJw6nAGA4@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-294631-21822@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294631 --- Comment #32 from Chad Jacob Milios <milios@ccsys.com> --- Sorry to shovel my pithy two cents onto this indomitable side debate; I can't help myself. These valid questions invariably come up in cases such as this and I can't remember resolutions, only bickering. (In reply to Joe Marcus Clarke from comment #27) (In reply to Oliver Lehmann from comment #28) Youre correct the theory and method are [crucially] supported; the results and outcomes of it, however not so much (or not at all, to be frank). It's the difference between flexibility-by-design vs consistency-by-design. Somewhat related, see also FPHB ยง 5.10.12 & 5.14.2. In a perfect world, the porter will succeed in their herculean and painstaking efforts, surgically and perfectly excising all instances of too-dang "cleverness" in distribution tarballs, with their myriad build systems. In practical reality, strict adherence to that ideal often results in more sluggish updates or would-be ports never existing in the first place. Using complicated measures to correctly build certain ports under all environments sometimes just leads to nearly-unmaintainable divergence from upstream code. This here however, not an auto-activation issue, was just an everyday run-of-the-mill [minor] logic bug which, if it weren't also a performance regression, could just as easily been met with an upstream response of wont-fix / just-dont-do-that-then (spurious symlink hanging around which, to be fair, they played no part in placing there). I also don't prefer Poudriere or Synth; so I don't use them. Thankfully, jails (or bHyVe) and nullfs (better yet, ZFS clones) are all included in our base system, operate reliably and for the most part seamlessly. (In reply to Charlie Li from comment #29) Thank you for allll you do; the whole Python ecosystem broadly speaking is IMNSHO a veritable hellscape. Meanwhile FreeBSD is [by leaps and bounds] my favorite development environment, its vigilance regarding sound engineering principles fostering copious opportunity for coherent integrations and ambitious innovations, largely in part to your replete diligence, tireless perseverance and abundant wizardry. Youre an absolute mensch. (In reply to Helge Oldach from comment #31) STAGEDIR solves/enables similar but not-quite-equivalent issues/features when compared to more-elaborate build platforms like Poudriere/Synth. Performance issue aside, this bug stems from py-installer (the genuine article, not the port) ignoring/forgetting its $destdir even only once. Our framework's make env/args are but mere humble requests and suggestions to the distributed build scripts/tools of dozens of thousands of constantly-changing softwares; nothing actually stops a tarball makefile, or anything downstream of it, from choosing to `LOL!=rm -rf /` or all manner of mischief in any syntax du jour. Only the curators of ports and admins of beefy stand between our precious systems/data and the many vibe-coding nose-pickers or even-worse supply-chain cretins. I don't think we actually want all such issues to be automagically solved in ports/Mk [by default or mandate] because we greatly benefit from the differing behaviors in various environments (and the underlying flexibility allowing it); diffing the output of `make configure` and/or the contents of STAGEDIR between varied environments helps me discover additional software functionality not yet exposed or understood by the port so available OPTIONS can much more easily and thoroughly be expanded, refined and/or supported. You might even be surprised one day to discover your most relied upon feature of your most cherished port in your most critical workflow was only ever made functional because cmake or its cousin violated our framework in a way the port maintainer never imagined and accounted for, when you built X locally in the presence of Y with a configuration of Z. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-294631-21822-HeJw6nAGA4>