/
TASKS
113 lines (79 loc) · 4.29 KB
/
TASKS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
SHARE-A-TASK
We need these tasks done, and anyone can do them.
Take one and run with it. Please.
--------
Filter dependency list against local system
Given a set of dependencies, some of which might be satisfied via locally
installed binaries/libraries/packages, determine which are still unresolved.
This will require some new subsystems (we can do these one at a time, slowly
handling more cases correctly, instead of trying to finish them all at once):
1. Keep track of which Plumage projects are currently installed, and all of
their related version information, and search against that info.
2. Implement a function that searches a path for binaries (like 'which').
Bonus points for determining "brand" and version as well.
3. Use %VM<config> to find local binary names for the basic build tools
and check that they are installed using the above function.
4. Implement a function that searches for system libraries and can
determine what "brand"/version the library represents.
5. Given a system package name, use apt/yum/etc. to determine if the
system package is installed and of the right version. (This is actually
several tasks, of course: one for each platform/packaging system.)
6. Design and implement some way to map agreed-upon virtual dependency names
to system package names on various platforms.
STATUS: Currently #1, #2, and #3 are partially implemented.
--------
Handle unresolved dependencies properly
Determine which unresolved dependencies can be handled by Plumage installing
additional projects on its own, and do so. For the remainder, help the user
figure out what to install to fulfill the missing dependencies.
STATUS: This is partially implemented.
--------
Test using local mock project repositories
Use 'git init' and 'svnadmin create' to build local repositories when
setting up Plumage's own test suite, so that our tests don't require
network access to work.
--------
Support file:/// URI scheme in Plumage::Downloader
Exactly what it says. We'll want this especially in Plumage's test suite,
to enable network-free testing. But our end users will want this too, for
private projects or local forks.
--------
Gracefully handle authenticated Subversion submodules
Most of the time when fetching from a source repository the top level project
checkout_uri will be public, and anyone will be able to download it. Not so
the submodules; in fact our very first Subversion project, Close, has private
(authenticated) submodules. If the user does not have the proper credentials
for a submodule, the fetch should gracefully continue on the assumption that
these submodules are not necessary for building the base project.
We will eventually need to deal with proper error handling if the top level
project itself requires unavailable credentials or the project won't build
with missing submodules, but that can probably be put off for now.
--------
Adding more "builtins" to Glue.pir:
The guiding principles are:
1. Do the most with the least.
2. It doesn't have to be perfect.
3. It's handy if the arguments are similar to the ones in Perl 6.
What we need:
* Filesystem
* Examples: file tests, directory tree walker, rm_rf, more?
* String slinging and especially filesystem path string munging
* Examples: more?
--------
Data structure merge/overlay
The basic use case: Take a data structure of default configuration or
metadata, overlay it with values from a "user defaults" JSON file, overlay
that with values from a parsed JSON file for a particular project, and then
overlay *that* with command line options or other runtime values.
Two possible ways to do this:
1. Actually merge the trees into a single data structure, replacing "older"
values with the same key path as "newer" values.
2. Make a proxy object that can store references to several data structures.
Any lookups in the proxy data structure are looked up in turn in each real
structure in order until a matching entry is found. Sets to the proxy are
passed on to only the real structure which is at the top of the "stack".
(For convenience in implementation, the writable structure may be special
in some way, such as always starting empty.)
STATUS: We already have a very simplified subset of this functionality (see
merge_tree_structures() in plumage.nqp), but I suspect we'll want the full
version before long.