Re: [pytest-dev] Documentation proposal

2017-08-06 Thread Daniele Procida
On Sat, Jul 15, 2017, Daniele Procida  wrote:

>I propose to restructure the pytest docmentation, according to this
>scheme  (the rationale for the
>scheme is described at length in that article).

Hi.

I have made a start on this since I first mentioned it at EuroPython.

You can see the work so far at 


To try it out locally:

Clone my branch and get into the right directory:

git clone -b documentation-restructure g...@github.com:evildmp/pytest.git
cd pytest/doc/en

Set up the virtualenv for the docs:

make install 

Start the documentation server:

make run

Checkout the new documentation at .

Please note that there remains a lot more to do, but there is enough so far to 
get an idea of:

* how it will be structured
* what it will like

I have many questions, which are in issues on my fork: 
. 

Because commits land so fast in master (over 200 since I started working on 
this less than a month ago) it would be good to get some feedback on this and 
know whether this approach is going to be accepted into pytest. If so, I will 
be able to continue, with two main tasks:

* build Brianna's tutorial into the documentation
* work through every single page and ensure that all content is correctly 
placed in the appropriate section.

Thanks,

Daniele

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev


Re: [pytest-dev] on opening up single character options via a registry

2017-08-06 Thread RonnyPfannschmidt


Am 06.08.2017 um 22:11 schrieb Floris Bruynooghe:
> RonnyPfannschmidt  writes:
>> as it pains me that we sneakily call private methods to use single
>> character options in xdist,
>> i propose to open up single character options to other plugins by means
>> of a registry,
> 
> What's wrong with the stance that this was a historical mistake and
> should never have been allowed?  It's a lot easier to handle, i.e. do
> nothing but apologise to plugin devs who want to use short options.

that is indeed an option,
i would prefer a way to have at least use the plugins under pytest-dev
use a well defined public specification in future

> 
>> so that plugins that have a registered single character will be able to
>> use it in py.test versions that have that association saved
>>
>> we could even go as far as making the registry a extra pytest plugin
>> that can be updated out of band from pytest itself
> 
> A plugin is probably the best way to go here.  It also means we'd be
> exposing the register functionality via hooks which is cute as it allows
> alternate registries to appear.  Your definition of cute may obviously
> vary, but I think this would work out fine and no chaos would ensue.
if we allow alternate registries for the pytest single character
options, then we just allow anyone to use anything after all.

collisions tend to be a pain, i believe its very helpful to have such a
registry as authoritative entity simply to avoid conflict for users

its already a pain to see the mess that's happening around marks and
mark name collisions, i don't see any compelling reason to repeat that
failure for options

-- Ronny

> >
> Cheers,
> Floris
> 
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev


Re: [pytest-dev] on opening up single character options via a registry

2017-08-06 Thread Floris Bruynooghe
RonnyPfannschmidt  writes:
> as it pains me that we sneakily call private methods to use single
> character options in xdist,
> i propose to open up single character options to other plugins by means
> of a registry,

What's wrong with the stance that this was a historical mistake and
should never have been allowed?  It's a lot easier to handle, i.e. do
nothing but apologise to plugin devs who want to use short options.

> so that plugins that have a registered single character will be able to
> use it in py.test versions that have that association saved
>
> we could even go as far as making the registry a extra pytest plugin
> that can be updated out of band from pytest itself

A plugin is probably the best way to go here.  It also means we'd be
exposing the register functionality via hooks which is cute as it allows
alternate registries to appear.  Your definition of cute may obviously
vary, but I think this would work out fine and no chaos would ensue.


Cheers,
Floris
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev