Mark tests that should not run without PyScaffold's src

[abravalheri]

Purpose

Some tests in our test suite assume specific conditions like having the source code available or running inside a virtual environment created by tox.
There are some circumstances though where users might want to obtain PyScaffold from a pre-packaged source and then just run the tests from a separated copy of the tests folder, specially when considering packaging forms other than wheels/pip.

Approach

This PR adds pytest marks that can be de-selected, so the tests under the mentioned assumptions will not run.

Resources & Links

See pyscaffold/pyscaffoldext-markdown#10 for the context motivating this PR.

[maresb]

This looks really great to me! I haven't tested it, but just from looking at it I'm fairly convinced it should work.

Unrelated note: I'm rewriting a detailed issue regarding git. I already wrote it yesterday with all the details and links, but forgot to click submit. Overnight my Github login expired, and I had to enter a new authenticator code. This morning I found the tab and hit submit, but it errored out, and I lost the entire writeup! Back button didn't work. 😢

[abravalheri]

Thank you very much for the review @maresb. I will merge the PR for now (and probably wait until more PRs are merged before tagging a new RC...). Let's open a new issue if the errors persist.

Sorry to hear about the on going issue... I hate when that happens.

[maresb]

Now that the pyscaffoldext-markdown recipe has been accepted and converted into a noarch feedstock, the conda-forge infrastructure no longer runs tests against Windows.

The big question is then whether or not we should run unit tests from conda-forge in the first place. Chris seemed to advise against it. I'm not so sure there is a significant benefit to it when the tests are already checked upstream, especially since conda-forge won't be checking Windows.

My inclination is to do unit testing from the pyscaffold package itself since the two of us have already put in the work, but to skip all but the basic tests for the extensions. In this sense I would deprioritize my recent feature request on pyscaffoldext-markdown. What do you think?

[abravalheri]

Hi @maresb, I like both approaches (yours and Chris' suggestions) to be sincere (in the end of the day, it was useful to have the failing test so we uncovered that specific corner case relates to conda + tox + build).

If the extensions rely solely on the tests generated by 'pyscaffoldext-custom-extension', the basic tests would be exactly the ones not marked with slow or system.

[maresb]

Ok, let's give it a shot. I just made conda-forge/pyscaffoldext-markdown-feedstock#2

Reminder: we have lost Windows testing through conda-forge since the package is now a feedstock with noarch.

I have a huge backlog of other projects I should be working on, and I've dumped all my thoughts, so I'm going to pull back now, except for routine maintenance. Thanks so much @abravalheri and @FlorianWilhelm , I've really learned a lot!

[abravalheri]

Thank you very much @maresb! You did a very huge contribution to PyScaffold, and I really liked working with you.

[FlorianWilhelm]

Thanks a lot, @maresb, that's so cool to finally have also some PyScaffold extensions as conda packages!

[maresb]

Likewise @abravalheri ! May I add you as a feedstock maintainer?

My pleasure @FlorianWilhelm, I'll likely see you around in the Hamburg mathematical DS scene / innovex meetups, etc., at least once I get vaccinated and can visit my employer again. :)

[FlorianWilhelm]

That would be awesome @maresb. Let me know when you are back in Hamburg. Then let's meet at the next inovex meetup there latest and have a beer.