public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Eli Schwartz <eschwartz93@gmail.com>
To: Ulrich Mueller <ulm@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
Date: Tue, 12 Sep 2023 22:07:31 -0400	[thread overview]
Message-ID: <1affddb8-221c-4c67-4395-03c2425d0e0e@gmail.com> (raw)
In-Reply-To: <uttrzkvx2@gentoo.org>

On 9/12/23 3:56 PM, Ulrich Mueller wrote:
>>>>>> On Tue, 12 Sep 2023, Eli Schwartz wrote:
> 
>> +				mkdir -p "${BUILD_DIR}" || die
>> +				local -x DIST_EXTRA_CONFIG="${BUILD_DIR}/extra-setup.cfg"
>> +				cat > "${DIST_EXTRA_CONFIG}" <<-EOF
>> +					[build]
>> +					build_base = ${BUILD_DIR}/build
>> +
>> +					[build_ext]
>> +					parallel = ${jobs}
>> +				EOF
> 
> "|| die" should also be added for the cat command.


Redirecting output to a file in a directory you have just guaranteed to
exist cannot fail. (mkdir -p will return nonzero and die, if it exits
without having guaranteed its target is a directory on disk. There is
one loophole, and that is if its target already existed beforehand, but
the mkdir -p process did not have write permissions for it; mkdir will
not check permissions if it detects it doesn't have to do work. This
should not be the case inside the workdir, or something has gone
significantly wrong beforehand.)

That being said, as a style guide concern I can see why being cautious
is generally desirable, as it's much easier to review code that uses it
when it isn't strictly necessary than code that doesn't use it when it
turns out to be necessary.

I'm not very used to this yet :) so I blindly assumed while writing it
that it wasn't necessary to do some additional typing and add this for
call sites that shouldn't be able to fail. I will add this in the next
revision.



-- 
Eli Schwartz



  reply	other threads:[~2023-09-13  2:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-12 19:14 [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options Eli Schwartz
2023-09-12 19:14 ` [gentoo-dev] [PATCH 2/2] python-utils-r1.eclass: unconditionally warn on occluded packages in cwd Eli Schwartz
2023-09-12 19:56 ` [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options Ulrich Mueller
2023-09-13  2:07   ` Eli Schwartz [this message]
2023-09-13  2:26     ` Michał Górny
2023-09-13  2:52       ` Eli Schwartz
2023-09-13  3:13         ` Sam James
2023-09-13  7:50         ` Alexey Sokolov
2023-09-13 13:10         ` Michael Orlitzky
2023-09-13 21:06           ` Eli Schwartz
2023-09-13  9:27     ` Ulrich Mueller
2023-09-13 21:06       ` Eli Schwartz
2023-09-14  8:24         ` Ulrich Mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1affddb8-221c-4c67-4395-03c2425d0e0e@gmail.com \
    --to=eschwartz93@gmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=ulm@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox