A powerful Sphinx changelog-generating extension.

Overview
https://secure.travis-ci.org/bitprophet/releases.png?branch=master

What is Releases?

Releases is a Python (2.7, 3.4+) compatible Sphinx (1.8+) extension designed to help you keep a source control friendly, merge friendly changelog file & turn it into useful, human readable HTML output.

Specifically:

  • The source format (kept in your Sphinx tree as changelog.rst) is a stream-like timeline that plays well with source control & only requires one entry per change (even for changes that exist in multiple release lines).
  • The output (when you have the extension installed and run your Sphinx build command) is a traditional looking changelog page with a section for every release; multi-release issues are copied automatically into each release.
  • By default, feature and support issues are only displayed under feature releases, and bugs are only displayed under bugfix releases. This can be overridden on a per-issue basis.

Some background on why this tool was created can be found in this blog post.

For more documentation, please see http://releases.readthedocs.io.

Note

You can install the development version via pip install -e git+https://github.com/bitprophet/releases/#egg=releases.

Issues
  • Unable to build -- Unknown node

    Unable to build -- Unknown node "issue"

    Hi despite having releases in the extensions list of my docs/source.conf.py I get the following error:

    pickling environment... done
    checking consistency... done
    preparing documents... done
    writing output... [ 31%] changes                                                                                                                                
    Exception occurred:
      File "/home/prologic/.virtualenvs/circuits/lib/python2.7/site-packages/sphinx/writers/html.py", line 588, in unknown_visit
        raise NotImplementedError('Unknown node: ' + node.__class__.__name__)
    NotImplementedError: Unknown node: issue
    The full traceback has been saved in /tmp/sphinx-err-8G5mEk.log, if you want to report the issue to the developers.
    Please also report this if it was a user error, so that a better error message can be provided next time.
    A bug report can be filed in the tracker at <https://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks!
    make: *** [html] Error 1
    
    Fatal error: local() encountered an error (return code 2) while executing 'make html'
    
    Aborting.
    
    opened by prologic 32
  • Support for crossing major-version boundaries

    Support for crossing major-version boundaries

    I.e. right now, in Paramiko, going from 1.x to 2.x results in: surprise! there's no 2.x displayed anywhere!

    Clearly the parse and/or organization logic breaks down in some way, which isn't too surprising, I'm sure there's a lot of assumptions baked in aimed squarely at iterating over minor releases only.

    Fixing this may end up solving (fully or partly) #19 and #36.

    Remaining todo

    • [x] Figure out whether we have solved #19 / #36 or not
    • [x] Address whether advanced spec format should imply major/backported behavior or not
    • [ ] Implement config option re: issues 'sticking' to latest major release family by default
    enhancement 
    opened by bitprophet 17
  • releases 1.3.1 sphinx version constraint too tough for pipenv, release new pypi version?

    releases 1.3.1 sphinx version constraint too tough for pipenv, release new pypi version?

    https://github.com/bitprophet/releases/compare/1.3.1...master

    f5fcad3 didn't make it in

    tmuxp-qUA_BCEU ❯ pipenv graph
    aafigure==0.6
    alagitpull==0.0.13
      - alabaster [required: ==0.7.10, installed: 0.7.10]
    pytest-rerunfailures==3.1
      - pytest [required: >=2.7.3, installed: 3.2.3]
        - py [required: >=1.4.33, installed: 1.4.34]
        - setuptools [required: Any, installed: 36.6.0]
    releases==1.3.1
      - semantic-version [required: <3.0, installed: 2.6.0]
      - sphinx [required: <1.5,>=1.3, installed: 1.6.4]
        - alabaster [required: >=0.7,<0.8, installed: 0.7.10]
        - babel [required: !=2.0,>=1.3, installed: 2.5.1]
          - pytz [required: >=0a, installed: 2017.2]
        - docutils [required: >=0.11, installed: 0.14]
        - imagesize [required: Any, installed: 0.7.1]
        - Jinja2 [required: >=2.3, installed: 2.9.6]
          - MarkupSafe [required: >=0.23, installed: 1.0]
        - Pygments [required: >=2.0, installed: 2.2.0]
        - requests [required: >=2.0.0, installed: 2.18.4]
          - certifi [required: >=2017.4.17, installed: 2017.7.27.1]
          - chardet [required: <3.1.0,>=3.0.2, installed: 3.0.4]
          - idna [required: >=2.5,<2.7, installed: 2.6]
          - urllib3 [required: <1.23,>=1.21.1, installed: 1.22]
        - setuptools [required: Any, installed: 36.6.0]
        - six [required: >=1.5, installed: 1.11.0]
        - snowballstemmer [required: >=1.1, installed: 1.2.1]
        - sphinxcontrib-websupport [required: Any, installed: 1.0.1]
    tmuxp==1.3.4
      - click [required: ==6.7, installed: 6.7]
      - colorama [required: ==0.3.9, installed: 0.3.9]
      - kaptan [required: >=0.5.7, installed: 0.5.8]
        - PyYAML [required: Any, installed: 3.12]
      - libtmux [required: ==0.7.5, installed: 0.7.5]
    
    opened by tony 9
  • fix crash when using sphinx > 1.3.4

    fix crash when using sphinx > 1.3.4

    opened by mindw 8
  • NotImplementedError: Unknown node: issue

    NotImplementedError: Unknown node: issue

    Using releases 0.6.1 and most earlier versions, I get the same exception as in #22 and #24. Here is the Sphinx error log :

    # Sphinx version: 1.2.2
    # Python version: 2.7.6
    # Docutils version: 0.11 release
    # Jinja2 version: 2.7.2
    # Loaded extensions:
    #   sphinx.ext.todo from /home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/sphinx/ext/todo.pyc
    #   sphinxcontrib.programoutput from /home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/sphinxcontrib/programoutput.pyc
    #   releases from /home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/releases/__init__.pyc
    #   sphinx.ext.intersphinx from /home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/sphinx/ext/intersphinx.pyc
    #   sphinx.ext.oldcmarkup from /home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/sphinx/ext/oldcmarkup.pyc
    Traceback (most recent call last):
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/sphinx/cmdline.py", line 254, in main
        app.build(force_all, filenames)
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/sphinx/application.py", line 212, in build
        self.builder.build_update()
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 214, in build_update
        'out of date' % len(to_build))
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 276, in build
        self.write(docnames, list(updated_docnames), method)
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 320, in write
        self._write_serial(sorted(docnames), warnings)
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 333, in _write_serial
        self.write_doc(docname, doctree)
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/sphinx/builders/html.py", line 433, in write_doc
        self.docwriter.write(doctree, destination)
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/docutils/writers/__init__.py", line 80, in write
        self.translate()
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/sphinx/writers/html.py", line 51, in translate
        self.document.walkabout(visitor)
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/docutils/nodes.py", line 174, in walkabout
        if child.walkabout(visitor):
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/docutils/nodes.py", line 174, in walkabout
        if child.walkabout(visitor):
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/docutils/nodes.py", line 174, in walkabout
        if child.walkabout(visitor):
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/docutils/nodes.py", line 174, in walkabout
        if child.walkabout(visitor):
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/docutils/nodes.py", line 174, in walkabout
        if child.walkabout(visitor):
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/docutils/nodes.py", line 174, in walkabout
        if child.walkabout(visitor):
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/docutils/nodes.py", line 174, in walkabout
        if child.walkabout(visitor):
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/docutils/nodes.py", line 174, in walkabout
        if child.walkabout(visitor):
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/docutils/nodes.py", line 166, in walkabout
        visitor.dispatch_visit(self)
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/docutils/nodes.py", line 1882, in dispatch_visit
        return method(node)
      File "/home/pmuller/dev/ipkg/env/lib/python2.7/site-packages/sphinx/writers/html.py", line 588, in unknown_visit
        raise NotImplementedError('Unknown node: ' + node.__class__.__name__)
    NotImplementedError: Unknown node: issue
    

    Since this changelog.rst does not belong to an opensource project, I'll send it to you by e-mail.

    I tried many versions of release; and the 0.2.4 version builds this changelog.rst file successfully. More recent ones do not.

    Thanks for your help !

    opened by pmuller 8
  • Allow multiple changelog files

    Allow multiple changelog files

    Fixes #59

    opened by MinchinWeb 7
  • Changelogs with no releases should appear as just 'unreleased'

    Changelogs with no releases should appear as just 'unreleased'

    Friend of the project @sivy tried to use it for a wholly-unreleased changelog (i.e. no :release: directives whatsoever) and ran into what is probably just an assumption-related bug. See https://gist.github.com/sivy/2cf88b595722ffcb7163 for details. Offhand we should be able to cope with this (the parsing step should end with just the 'unreleased' release object holding all issues, and render as such).

    bug 
    opened by bitprophet 7
  • More Sphinx 1.6 problems

    More Sphinx 1.6 problems

    Sort of a follow-on from #71, which prompted me to dig deeper into how we were not really compatible with Sphinx 1.5/1.6.

    Sphinx 1.5 was just due to Python 2.6 being dropped, so we did that here too, and no problem.

    Sphinx 1.6 made a lot of internal API changes that broke us. I fixed all the stuff that seems to pop up in our test suites, but there's a side channel - parsing the changelog 'in-process' for stuff like my release Invoke tasks (which need to answer questions about a project's changelog state.)

    Specifically, something seems to be almost skipping Sphinx itself when rendering, leaving us with "I'm docutils and what is this???" errors like:

    image

    Well...clearly :doc: should freaking work in Sphinx-flavored RST! (It also complained about a :ref: that I temporarily commented out.)

    opened by bitprophet 7
  • Better plan/docs for master-only, young projects

    Better plan/docs for master-only, young projects

    Problem

    • Young projects with just a master branch & rapid iteration (like...this project) are often tempted to slam out arbitrary feature releases ("ehhh let's call this 0.3.0"), sometimes with bugfix releases in between, sometimes not - but almost always w/o really keeping release lines, numbers just go up.
    • In this setup, the distinction between feature and bugfix releases can be blurred or nonexistent.
    • That clashes with how Releases thinks about the world (namely, from a mature-project, multiple-release-line perspective.) Young projects must constantly remember to mark bugs as 'major', at the very least.

    Solutions

    1. Education only: document the phenomenon of pre-1.0 single-line release setups, remind that "mixed" releases will need to mark up the bugs and/or features as appropriate so they show up right.
    2. Logic update: pre-1.0 releases are considered to consume all issues listed since previous release. Maybe make this configurable for users who don't want it.
      • Counterpoint: this could confuse users since the behavior changes post 1.0, possibly "without warning."
    3. Do both: document it, make an opt-in (not opt-out) option saying "yes I want lazy pre-1.0 releases that suck up all issues".

    Last feels best.

    opened by bitprophet 7
  • Multiple Changelog files?

    Multiple Changelog files?

    I have enjoyed using releases on several projects and am looking to use it on several more.

    I am wondering if it is possible to process multiple "changelog" files?

    The particular situation I have is that I have several small projects around a common theme. I would like to maintain a changelog per project, but would like to maintain only one documentation site for the lot of them. Suggestions on how to do this?

    enhancement 
    opened by MinchinWeb 7
  • 1.6.3: issue with man page generation using sphinx

    1.6.3: issue with man page generation using sphinx

    Just found that I'm not able to generate man page in sphinx-theme-alabaster python module (https://github.com/bitprophet/alabaster/)

    + sphinx-build -b man -d sphinx-theme-alabaster docs .
    Running Sphinx v3.5.3
    building [mo]: targets for 0 po files that are out of date
    building [man]: all manpages
    updating environment: [new config] 4 added, 0 changed, 0 removed
    reading sources... [ 25%] changelog
    Extension error (releases):
    Handler <function generate_changelog at 0x7f85d9b5eee0> for event 'doctree-read' threw an exception (exception: Call either Version('1.2.3') or Version(major=1, ...).)
    
    opened by kloczek 1
  • 1.6.3: test suite warnings

    1.6.3: test suite warnings

    + /usr/bin/python3 setup.py test
    running test
    WARNING: Testing via this command is deprecated and will be removed in a future version. Users looking for a generic test entry point independent of test runner are encouraged to use tox.
    running egg_info
    writing releases.egg-info/PKG-INFO
    writing dependency_links to releases.egg-info/dependency_links.txt
    writing requirements to releases.egg-info/requires.txt
    writing top-level names to releases.egg-info/top_level.txt
    reading manifest file 'releases.egg-info/SOURCES.txt'
    reading manifest template 'MANIFEST.in'
    warning: no previously-included files matching '*' found under directory 'docs/_build'
    warning: no previously-included files matching '*.pyc' found under directory 'tests'
    warning: no previously-included files matching '*.pyo' found under directory 'tests'
    writing manifest file 'releases.egg-info/SOURCES.txt'
    running build_ext
    /home/tkloczko/rpmbuild/BUILD/releases-1.6.3/.eggs/semantic_version-2.6.0-py3.8.egg/semantic_version/base.py:94: SyntaxWarning: "is" with a literal. Did you mean "=="?
      if self.prerelease and self.minor is 0 and self.patch is 0:
    /home/tkloczko/rpmbuild/BUILD/releases-1.6.3/.eggs/semantic_version-2.6.0-py3.8.egg/semantic_version/base.py:94: SyntaxWarning: "is" with a literal. Did you mean "=="?
      if self.prerelease and self.minor is 0 and self.patch is 0:
    /home/tkloczko/rpmbuild/BUILD/releases-1.6.3/.eggs/semantic_version-2.6.0-py3.8.egg/semantic_version/base.py:100: SyntaxWarning: "is" with a literal. Did you mean "=="?
      if self.prerelease and self.patch is 0:
    
    ----------------------------------------------------------------------
    Ran 0 tests in 0.000s
    
    opened by kloczek 1
  • Pinned semantic-version causes conflicts

    Pinned semantic-version causes conflicts

    A while ago semantic-version was pinned to <2.7. This is now starting to cause problems as other packages are moving to require newer versions (in our case py-solc-x which requires semantic_version>=2.8.1,<3).

    I see that there's #86 (and the reworked branch based on that). Would it help for someone else to pick that up, or do you already know what needs to be done?

    opened by ulope 1
  • Adding new :deprecation: and :removal: categories

    Adding new :deprecation: and :removal: categories

    Over at pygae/galgebra, a lot of my release notes are of the form The function :func:useless_functionwas deprecated. Since these are neither features nor bugfixes, we're currently categorizing them as :support:.

    Would it be possible to introduce some more categories? Specifically, I'm finding myself wanting:

    • :deprecation:, for functions which have been changed to emit a warning upon use.
    • :removal:, for features which have been removed (typically those marked with :deprecation: in a previous release).
    opened by eric-wieser 0
  • Feature Request: Special Unstable-Prehistory-Mode that's not disabled after 1.0.0

    Feature Request: Special Unstable-Prehistory-Mode that's not disabled after 1.0.0

    Reasoning behind the request

    Hello!

    So I have a feature request which may sound strange to you as it does not 100% follow the semantic versioning ethos. But there are projects like mine which like things simple. I want all issues under a release to be put as part of that release when rendered.

    So essentially what unstable-prehistory-mode does, except I want it to also carry on after v1.0. I know I can start specifying which issue belongs to each release, but at that point I am fighting the tool instead of using it.

    Why you may ask? For our project:

    • Each minor release after v1.0 is feature heavy (and perhaps some bugs).
    • Each patch release is mostly quick hotfixes for stuff that break a previous minor release.
    • And we are a bit reluctant to use the major version number. So no v2.0 soon.

    With the above characteristics the default way the tool operates does not really work.

    Feature request specification

    Add a new switch that essentially does not stop the unstable-prehistory-mode after v1.0.

    opened by LefterisJP 2
  • Fix util module for Sphinx 1.8+

    Fix util module for Sphinx 1.8+

    After #87 I found that Releases itself still works OK, but our util module (used by invocations' release package to parse Releases changelogs as a way of ensuring one has updated one's changelog) broke - it does things the main part of Releases doesn't need to, basically trying to fake Sphinx into rendering a project in-memory instead of on-disk.

    Took a brief stab at it in https://github.com/bitprophet/releases/tree/sphinx-1.8-plus-broke-utils but once I fix outright explosions, I still end up with a rendered doctree which is missing our custom objects (though things like :ref: still work, re: the final block of util.get_doctree's comment about it being necessary). They're just the default 'raw' objects instead.


    For the time being I am updating the test suite / Travis config to ignore the utils module as it's not technically required for Releases to function (I'm almost certainly the only user of utils).

    My suspicion is that the simplest way forward here is to stop worrying about any Sphinx <1.8 (maybe even <2), just try to get this working again (even if it means starting over from scratch), and release the fix as Releases 1.7 which changes the Sphinx pin again to be >=1.8/2.0.

    Rationale for that last, besides salvaging the remaining shreds of my sanity, is that if even conservative ol' me is having issues trying to run Sphinx <1.8 in today's ecosystem, very few other users are going to be caring about those versions. Better to cut the chaff and, if necessary, merge patches from folks to support Releases <=1.6.x on the older Sphinxes if critical bugs pop up.

    opened by bitprophet 2
  • Infer dates from tags

    Infer dates from tags

    I really like what releases has done, and I'm considering adopting it in place of the technique I've ~~developed~~cobbled together, which performs textual substitution on the .rst to inject links.

    One feature I'd miss dearly in a transition to releases, however, is the date inference. Rst.linker will inject a timestamp based on SCM metadata (the date the tag was created). This approach allows a maintainer to simply publish the release version, but get release dates reflected in the published docs.

    Perhaps releases could offer this behavior as an opt-in feature, maybe by default if no <date> is supplied in the release directive.

    opened by jaraco 0
  • the releases extension does not declare if it is safe for parallel reading

    the releases extension does not declare if it is safe for parallel reading

    the follow error is raising here:

    Warning, treated as error:
    the releases extension does not declare if it is safe for parallel reading, assuming it isn't - please ask the extension author to check and make it explicit
    

    does anyone know how to fix that?

    opened by xmnlab 1
  • Fix compatibility with >=python-semanticversion-2.7.0

    Fix compatibility with >=python-semanticversion-2.7.0

    Context

    The recent versions of python-semanticversion made changes to private APIs, removing the interaction between Version(x, partial=True) and Spec() (partial=True was designed for implementing the Spec class only).

    This breaks releases, has mentioned in #84 and #85; it has also been reported as affecting twine's doc building (https://github.com/pypa/twine/issues/492).

    The attached patch switches to the recommended usage of python-semanticversion (whose docs are still lacking in that regard, sorry :disappointed:), while keeping all tests green - both with updated and old python-semanticversion releases.

    Implementation notes

    The code used Version(..., partial=True) to exclude ranges of version whose major component didn't match a bugfix/issue range; the code went akin to:

    Version('1', partial=True) in Spec('>=1.0')
    

    This no longer works; this patch changes that behaviour to exclude families where no actual release matches the bugfix/issue range - this should be more accurate.

    The patch also uses Version.coerce, the intended API to manage non semver-compliant version strings.

    Compatibility

    The patch has been tested with both python-semanticversion==2.6.0 and python-semanticversion==2.8.1; it can be included to an upgraded version of releases even if users haven't yet upgraded python-semanticversion.

    opened by rbarrois 10
  • List six package as a dependency

    List six package as a dependency

    Used in files releases/models.py and releases/__init__.py.

    opened by jdufresne 0
Owner
Jeff Forcier
Developer/sysadmin. Maintainer of fine Python automation tools. Tries balancing 'done right' & 'done on time'; occasionally succeeds. He/him.
Jeff Forcier
Type hints support for the Sphinx autodoc extension

sphinx-autodoc-typehints This extension allows you to use Python 3 annotations for documenting acceptable argument types and return value types of fun

Alex Grönholm 387 Jan 14, 2022
Main repository for the Sphinx documentation builder

Sphinx Sphinx is a tool that makes it easy to create intelligent and beautiful documentation for Python projects (or other documents consisting of mul

null 4.4k Jan 18, 2022
A curated list of awesome tools for Sphinx Python Documentation Generator

Awesome Sphinx (Python Documentation Generator) A curated list of awesome extra libraries, software and resources for Sphinx (Python Documentation Gen

Hyunjun Kim 778 Jan 5, 2022
Main repository for the Sphinx documentation builder

Sphinx Sphinx is a tool that makes it easy to create intelligent and beautiful documentation for Python projects (or other documents consisting of mul

null 4.4k Jan 19, 2022
Sphinx theme for readthedocs.org

Read the Docs Sphinx Theme This Sphinx theme was designed to provide a great reader experience for documentation users on both desktop and mobile devi

Read the Docs 3.9k Jan 13, 2022
Numpy's Sphinx extensions

numpydoc -- Numpy's Sphinx extensions This package provides the numpydoc Sphinx extension for handling docstrings formatted according to the NumPy doc

NumPy 194 Jan 10, 2022
ReStructuredText and Sphinx bridge to Doxygen

Breathe Packagers: PGP signing key changes for Breathe >= v4.23.0. https://github.com/michaeljones/breathe/issues/591 This is an extension to reStruct

Michael Jones 569 Jan 14, 2022
Watch a Sphinx directory and rebuild the documentation when a change is detected. Also includes a livereload enabled web server.

sphinx-autobuild Rebuild Sphinx documentation on changes, with live-reload in the browser. Installation sphinx-autobuild is available on PyPI. It can

Executable Books 371 Jan 9, 2022
sphinx builder that outputs markdown files.

sphinx-markdown-builder sphinx builder that outputs markdown files Please ★ this repo if you found it useful ★ ★ ★ If you want frontmatter support ple

Clay Risser 118 Jan 12, 2022
Sphinx Bootstrap Theme

Sphinx Bootstrap Theme This Sphinx theme integrates the Bootstrap CSS / JavaScript framework with various layout options, hierarchical menu navigation

Ryan Roemer 577 Dec 2, 2021
📖 Generate markdown API documentation from Google-style Python docstring. The lazy alternative to Sphinx.

lazydocs Generate markdown API documentation for Google-style Python docstring. Getting Started • Features • Documentation • Support • Contribution •

Machine Learning Tooling 60 Jan 12, 2022
Seamlessly integrate pydantic models in your Sphinx documentation.

Seamlessly integrate pydantic models in your Sphinx documentation.

Franz Wöllert 40 Jan 6, 2022
Speed up Sphinx builds by selectively removing toctrees from some pages

Remove toctrees from Sphinx pages Improve your Sphinx build time by selectively removing TocTree objects from pages. This is useful if your documentat

Executable Books 5 Oct 26, 2021
python package sphinx template

python-package-sphinx-template python-package-sphinx-template

Soumil Nitin Shah 2 Dec 7, 2021
epub2sphinx is a tool to convert epub files to ReST for Sphinx

epub2sphinx epub2sphinx is a tool to convert epub files to ReST for Sphinx. It uses Pandoc for converting HTML data inside epub files into ReST. It cr

Nihaal 4 Dec 17, 2021
A `:github:` role for Sphinx

sphinx-github-role A github role for Sphinx. Usage Basic usage MyST: :caption: index.md See {github}`astrojuanlu/sphinx-github-role#1`. reStructuredT

Juan Luis Cano Rodríguez 3 Nov 30, 2021
This is a template (starter kit) for writing Maturity Work with Sphinx / LaTeX at Collège du Sud

sphinx-tm-template Ce dépôt est un template de base utilisable pour écrire ton travail de maturité dans le séminaire d'informatique du Collège du Sud.

null 7 Dec 9, 2021
Simple yet powerful CAD (Computer Aided Design) library, written with Python.

Py-MADCAD >>> it's time to throw parametric softwares out ! Simple yet powerful CAD (Computer Aided Design) library, written with Python. Installation

jimy byerley 45 Jan 13, 2022
Generating a report CSV and send it to an email - Python / Django Rest Framework

Generating a report in CSV format and sending it to a email How to start project. Create a folder in your machine Create a virtual environment python3

alexandre Lopes 1 Jan 17, 2022