I think at some point I wanted to unify this implementation with sass.compile_dirname -- though to me it's really unclear if anyone actually uses this functionality in its current state (due to the odd extension)

I just use it today by using distutils, hence that quick fix.

I try to migrate the compilation of my Sass code built by the legacy Ruby compiler with the Python version. Except the color issue and this one, all seems to be fine.

It would be better to add a bool parameter to determine whether to remove the .scss suffix or maintain the legacy behavior. After defaulting the legacy behavior for several minor releases (warning messages as well may be necessary), we'll be able to change the default behavior.

Well, darn it. I'm also trying to replace the Ruby legacy compiler in our toolchain with libsass and distutils, and just hit upon this same snag; all our output files are now named differently, since the .css part isn't stripped.

Two questions:

1. Why are there separate overlapping implementations of this functionality in sass.compile_dirname and sassutils.build_directory?
2. What can I do to help close Strip Sass extension from output file #55? I'm not sure I know distutils well enough yet to implement a boolean parameter, as @dahlia suggests...

Why are there separate overlapping implementations

Originally sass.compile(dirname=...) was a thin wrapper around libsass's sass_compile_folder functionality -- however sass_compile_folder was removed and so that functionality was reimplemented in pure python as sass.compile_dirname: 202d657

What can I do to help close #55?

There's really only two parts to distutils integration, first you need to tell distutils the parameter exists and then use it!

In this case you'd need to funnel along something like sass_strip_extension into the sasutils.builder machinery

Thanks, @asottile . I seem to be having some other issues with how the distutils integration adds compiled css files to the distutils manifests, but I'll have to make a simpler proof-of-concept prototype just to see that the problem isn't just on my end.

However, I'll be at EuroPython next week (which may or may not improve my chances of looking at this) - and following that, I'm off on three weeks vacation - so there might be some time before I make myself heard again ;-)

This'll be available in the next release (0.15.0) via #258 and #260 -- thanks for the PR!