1. 24 Mar, 2022 1 commit
  2. 16 Feb, 2022 2 commits
  3. 10 Oct, 2021 1 commit
  4. 23 Sep, 2021 1 commit
  5. 03 Sep, 2021 1 commit
    • Stephen Finucane's avatar
      Remove references to the generic :py:obj: role (#54) · e3d99f53
      Stephen Finucane authored
      tl;dr: We shouldn't be using the 'obj' roles from the Python domain.
      
      The Python domain provides the 'obj' role as a generic, "catch all" way
      to refer to any Python object of an unspecified type [1]. Unfortunately
      we were erroneously making use of this role in two places.
      
      The first of these is our doc fields [2], which we use to provide
      information about request and response attributes, such as query
      parameters (e.g. ':query foo:') or request parameters in the body (e.g.
      ':param bar:'). These are implemented using 'TypedField' because we want
      to provide type information. For example:
      
        :query offset: offset number. default is 0
        :type offset: int
      
      The 'TypedField' class allows you to specify a 'typerolename', which
      determines the role that is automatically associated with a parameter
      type with an object. For example, consider this example for the Python
      domain:
      
        .. py:class:: User
      
           A user.
      
        .. py:function:: delete_user(user)
      
           Delete a user.
      
           :param user: The user to be deleted
           :type user: User
           :rtype: :class:`None`
      
      Because the Python domain implements support for the 'param' doc field
      using typerolename='class', the 'User' in ':type user: User' effectively
      resolves to ':type user: :py:class:`User`' (*effectively* - there are
      some differences). Since we don't provide an 'obj' role like the Python
      domain does, we probably don't want to use this. We certainly don't want
      to link to things in the Python domain, if that was even an option. As
      such we simply drop the 'typerolename' attribute from our 'TypedField'
      usages, thus disabling this "auto-linking" (which never would have
      worked anyway).
      
      The other place we're using the 'obj' role is in our definition of
      'object_types' as part of the 'HTTPDomain' domain. This attribute is
      supposed to list the type of objects that the domain will index - things
      like classes and functions for the Python domain, or PUT and GET
      requests for the HTTP domain. This is implemented by a mapping of types
      to 'ObjType' instances, which in turn take the following arguments [3]:
      
        - *lname*: localized name of the type (do not include domain name)
        - *roles*: all the roles that can refer to an object of this type
        - *attrs*: object attributes -- currently only "searchprio" is known,
          which defines the object's priority in the full-text search index,
          see :meth:`Domain.get_objects()`.
      
      We were passing two roles for each object type. The first of these
      mapped to the name of a directive used to document said object, e.g. an
      ':options:' role to refer to an '.. option::' directive. The latter was
      a generic ':obj:' role. This is clearly a hangover from the Python
      directive, where, as noted previously, this would allow one to use the
      ':obj:' role to refer to *any* indexed Python object rather than using
      object-specific roles like ':class:'. However, have no such generic role
      defined for the HTTP domain and it probably wouldn't make sense to have
      one. Therefore, we can and should simply drop this.
      
      [1] https://www.sphinx-doc.org/en/master/usage/restructuredtext/domains.html#role-py-obj
      [2] https://github.com/sphinx-doc/sphinx/blob/v4.1.2/sphinx/util/docfields.py#L1-L10
      [3] https://github.com/sphinx-doc/sphinx/blob/v4.1.2/sphinx/domains/__init__.py#L40-L44
      
      
      
      Signed-off-by: default avatarStephen Finucane <stephen@that.guru>
      Closes: #53
      e3d99f53
  6. 02 Sep, 2021 1 commit
  7. 16 Aug, 2021 1 commit
  8. 22 Mar, 2021 3 commits
  9. 10 Mar, 2021 2 commits
  10. 05 Mar, 2021 3 commits
  11. 16 Feb, 2021 2 commits
  12. 03 Dec, 2020 1 commit
  13. 24 Nov, 2020 1 commit
  14. 12 Nov, 2020 2 commits
  15. 11 Nov, 2020 1 commit
  16. 18 Apr, 2020 3 commits
  17. 08 Sep, 2019 1 commit
  18. 18 Jul, 2019 1 commit
  19. 29 Nov, 2018 4 commits
  20. 30 Oct, 2018 2 commits
  21. 03 Aug, 2018 1 commit
  22. 01 Jul, 2018 5 commits