1. 20 Oct, 2016 6 commits
  2. 01 Sep, 2016 1 commit
  3. 30 Aug, 2016 3 commits
  4. 29 Aug, 2016 1 commit
  5. 26 Aug, 2016 1 commit
  6. 05 Jul, 2016 1 commit
  7. 01 Jul, 2016 1 commit
    • Added missing classifiers to the `setup.py` · aef2c094
      I have added extra topics:
      
      ```
      +        'Topic :: Software Development :: Libraries :: Python Modules',
      +        'Topic :: Internet :: WWW/HTTP',
      +        'Topic :: Internet :: WWW/HTTP :: Dynamic Content',
      ```
      
      Added information about framework:
      
      ```
      'Framework :: Django',
      'Framework :: Django :: 1.6',
      'Framework :: Django :: 1.7',
      'Framework :: Django :: 1.8',
      'Framework :: Django :: 1.9',
      ```
      
      And `python` versions:
      
      ```
              'Programming Language :: Python :: 2.7',
              ...
              'Programming Language :: Python :: 3.4',
              'Programming Language :: Python :: 3.5',
              'Programming Language :: Python :: Implementation :: PyPy',
      ```
      
      I have also sorted the classifiers alphabetically.
      Sobolev Nikita committed
  8. 11 Jun, 2016 2 commits
  9. 07 Jun, 2016 1 commit
  10. 28 May, 2016 1 commit
  11. 08 May, 2016 1 commit
  12. 31 Mar, 2016 3 commits
  13. 30 Mar, 2016 1 commit
  14. 29 Mar, 2016 2 commits
  15. 23 Mar, 2016 1 commit
    • Switch to using os.path for outdated file checks in compilers. · 930b12c9
      The outdated file checks in the compilers were using django storages to check
      file existence and compare mtimes, but with my recent change (which restored
      the older behavior of comparing the infile and outfile), these were operating
      on absolute, local files, which could result in a SuspiciousFileOperation.
      
      The compilers always operate on local files, so we can switch to using the
      os.path methods for these instead. This is both more correct and more
      efficient.
      David Trowbridge committed
  16. 22 Mar, 2016 2 commits
  17. 21 Mar, 2016 2 commits
    • Merge pull request #552 from chipx86/templatetags/split-render-func · 0dc58580
      Split render_compressed in templatetags for easier subclassing
      David Trowbridge committed
    • Split the render_compressed method in templatetags for easier subclassing. · b647cf55
      The base mixin for the template tags, PipelineMixin, performed the bulk
      of its rendering logic in the render_compressed() method. It handled
      both rendering output files (if PIPELINE_ENABLED was True), or source
      files (if False). Due to the complexity of this method, it was difficult
      for a subclass (which may need to perform more specialized logic) to
      override this method without copying the code.
      
      This splits out that function into two new utility methods,
      render_compressed_sources() and render_compressed_output(). These take
      the same arguments as render_compressed(), and are called by that method
      as well. This allows a subclass to more easily replace the logic for
      determining which to call, or to replace the logic for either of these
      renders.
      Christian Hammond committed
  18. 10 Mar, 2016 6 commits
  19. 07 Mar, 2016 1 commit
  20. 06 Mar, 2016 1 commit
    • Add error output for compiler errors within the browser. · 3b5c5a22
      Debugging CSS/JavaScript compilation errors can be difficult when viewed
      within the context of a Django error page, and if there's a wider
      problem with other CSS/JavaScript packages, they won't show up until the
      first compilation error is fixed. This is worse if running in a mode
      where Pipeline is running but Django error pages aren't being shown.
      
      This change introduces an option, PIPELINE.SHOW_ERRORS_INLINE (now
      enabled by default) that outputs any compilation errors at the top of
      the page, visually distinguished from the rest of the page, and
      containing information on the failing package, command line, and output.
      This makes it much easier to debug what went wrong.
      
      The errors are outputted into a hidden div, and then once the page has
      fully loaded, they're placed at the top. This allows Pipeline usage
      anywhere on the page to promote errors to the top, in the order in which
      they're loaded. These also have a default style, but that can be
      overridden (and in fact the whole error template overridden) by the
      consuming application.
      Christian Hammond committed
  21. 26 Feb, 2016 1 commit
  22. 24 Feb, 2016 1 commit