dasmithii / kit Goto Github PK

Libraries written under the management of Kit are hard to distribute, especially when these libraries depend on modules in the Kit index.

For C developers who aren't willing to adopt a new project manager, we should provide a kit dist command. This would fetch dependency sources, replace Kit-based include statements, and wrap everything into a [mostly] self-contained project.

C++ projects may link with C modules, but the contrary is not true, so there should be something to prevent accidental inclusions of C++ sources when only C sources are permitted.

Module name collisions are another issue.

Some projects require libraries outside of kit, need specific versions of C, or do other important things that kit leaves unsupported.

An optional configuration file, maybe?

#include <kit/module/file.h

should read

#include <kit/module/file.h>

Traceback (most recent call last):
  File "D:\Python34\Scripts\kit-script.py", line 9, in <module>
    load_entry_point('Kit==0.1', 'console_scripts', 'kit')()
  File "D:\Python34\lib\site-packages\pkg_resources.py", line 353, in load_entry
_point
    return get_distribution(dist).load_entry_point(group, name)
  File "D:\Python34\lib\site-packages\pkg_resources.py", line 2302, in load_entr
y_point
    return ep.load()
  File "D:\Python34\lib\site-packages\pkg_resources.py", line 2029, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "D:\Python34\lib\site-packages\kit-0.1-py3.4.egg\kit\main.py", line 3, in
 <module>
ImportError: No module named 'commands'

Are there any dependencies that need to be installed to run Kit?

The upstart time for Kit is too slow. This isn't a bug, but it would be nice to speed things up a bit.

I think the primary cause is an overabundance of import statements. The code is organized in such a way that requires many imports in each module, which, according to this link, may increase startup overhead. Some refactoring might help. Lazy imports are another option (can they be made automatic in any way?).

Other potential areas of improvement:

• the scanner and its recursive globbing of source files
• makefiles in the context of parallel compilation (this might not help during startup, but it'll speed things up nevertheless)

At this point, modules are treated identically regardless of their version. This poses a problem when library APIs change and undermine existing codebases.

TODO

The output of Kit is pretty chaotic, especially when fetching modules from the central repo. We should clean everything up a bit a some point.

With a few changes to builder.py, C++ modules could be supported alongside C modules, since these languages share the same compilation process.