Re: [PATCH] Unit-test for Please add support for dlangs packagemanager to ob-C.el

[Ihor Radchenko <yantar92@gmail.com>]

<Please use Reply-All button when replying. Otherwise, the discussion is
not recorded in the mailing list and other Org contributors cannot read it>

<I am CCing Bastien and Org mailing list back in this email>

Christian Köstlin <christian.koestlin@gmail.com> writes:

>> If the programming language is using its own package manager, is it any
>> different? Or do you refer to something else?
>>
> Most of the packages that a programming language like rust/crates,
> ruby/rubygems
> or dlang/dub-packages provide will probably never make it into the package
> management system of the operating system. Also the programming language
> package management usually has finer grained dependency management.
> But it's just a theoretical question as no other ob-* integration
> integrates a package
> manager at the momen.

If we do anything about such integration, we should not enable such
testing automatically. What we certainly do not want is unsuspecting
user running make test and getting some packages installed into his/her
computer.

However, the side effects requiring installing certain packages to the
OS might be shielded behind Makefile customization that will be set to
non-nil in CI tests. Of course, such customization should be documented
in testing/README.

>>> Throwing the 'missing-test-dependency has exactly same result, but also
>> >> allows making our test suite indicate such issues simply by altering
>> >> the 'missing-test-dependency catch code. That's why prefer
>> >> 'missing-test-dependency approach.
>> >>
>> > Nice ... I just tested the aforementioned `(ert--skip-unless
>> > (executable-find "dub")`
>> > which also works nicely. I could post another patch that updates the
>> whole
>> > test-ob-C.el with one of those strategies.
>> I am confused. Why do you need to use internal ert function?
>>
> I just tried what was proposed in one of the other emails ...

I do not blame you. Do not take it for granted that every Org
contributor, maintainer, or mailing list dweller is always right.

In this particular case, I disagree with Max and I tried to put
arguments why I disagree. If you think that I am wrong, you can refute
my arguments.

>> Note that we only have skip-unless feature in
>> ob-shell/remote-with-stdin-or-cmdline, which is probably just an
>> incident.
>>
>> Most of the test files use (signal 'missing-test-dependency ...)
>> For example, at the very top of test-ob-C.el:
>>
>> (unless (featurep 'ob-C)
>>   (signal 'missing-test-dependency "Support for C code blocks"))
>>
>> We even have a dedicated function to test if executable exists:
>> `org-test-for-executable':
>>
>> (org-test-for-executable "awk")
>> (unless (featurep 'ob-awk)
>>   (signal 'missing-test-dependency "Support for Awk code blocks"))
>>
> yes .. the difference is, that with org-test-for-executable i get a failing
> test (same for `signal 'missing-test-dependency`)
> with the ert function one gets a skipped test.

I guess you tried to throw 'missing-test-dependency _inside_ the test.
AFAIK, 'missing-test-dependency is caught when test-*.el file is being
loaded, not when the ERT tests are being executed. See `org-test-load'.

I think you can create a separate file like test-ob-D.el and run
(org-test-for-executable ...) at the top-level there.

> There is only one most important policy - if we recommend anything
>> publicly, it must be Free software. The detailed rules are covered by
>> https://www.gnu.org/prep/maintain/maintain.html
>
> yes ... still i am now lawyer enough to e.g. judge if gitlab/github is
> according
> to that.

We generally avoid GitHub because of some of their practices (see
https://www.fsf.org/search?SearchableText=github).

However, FSF policy is of a secondary importance here.

WRT CI tooling, we just prefer something Org maintainers do use.
Bastien, the chief maintainer, prefers Sourcehut.
Since he maintains the Org infrastructure, we should also prefer
Sourcehut, unless there are strong reasons to use other service. (Do not
hesitate to name those reasons, if you know any)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>