Open twolfson opened 10 years ago
Fragmentation notes from a few nights back:
sublime_text --command
trigger)The take away from the last comment: Fragment off a harness repo which allows for adding and running an arbitrary Python command in sublime from the command line. It should include namespacing of the command/directories so they can be run concurrently without the potential for conflict.
The testing framework would build on top of that with writing out results to a file then parsing them as if it were a test (current situation).
Tests that we need with respect to the execfile
fiasco:
import sys
def main():
# This should be retained, eval + compile lost them =(
return sys
Work for execfile
+ Sublime Text 3 can be found in 04dc0a5
Fragments:
For fragmentation, a separate launcher/harness would make the most sense
Sublime info package which has:
More notes from last night:
Installer - bash script to perform Travis installs
Info - ST locations, pkg dir
Launcher with namespace - Launch ST under a specific namespace
Assertion - Base layer of TDD and other testing implementations (provides try
/catch
/finally
harness and wrapper)
TDD - Thin layer around unittest.TestCase
to use all test cases under the Assertion layer
Make Sublime Text installer standalone and possibly python-less
curl | sh
Definitely semver the bash script
I still don't know the complexity of releasing small modules for Python but to stay as true to "One Thing Well" as possible, we should fragment this repo.
The
utils
seem like they each could be fragmented and optimized (selection
is a perfect example of expanding scope for open source).The
base
andTestCase
could be separated into different repositories for specialized tests and quicker debugging.