Pass pacakge names internally as symbols #658
Conversation
Assertions have been added to many functions that take packages or lists of packages to enforce this. by itself, this breaks el-get horribly, because other functions must also be modified not to pass strings when they call these functions.
The function "el-get-as-symbol" is only used in interactive functions that accept user input. All other functions assume packages are passed and returned as symbols.
|
Well I guess that if you run the test suite against the assert-enabled branch that would allow us ascertain we're only using symbols internally. Do we need to include the asserts in the official el-get code (not opposed to it per-se, only curious). |
|
No, we don't. That's why I put them in a separate commit, so I could easily revert them later. I've run the test suite against this branch, and all the tests passed. |
|
I'm not convinced we should install the asserts, however, please do as you see fit. Maybe with a new function |
|
No, we shouldn't install the asserts. They're just for testing purposes, so that any package-names passed as strings will get caught quickly during testing with a predictable error message. |
|
As you see fit, and thanks agin for all the testing :) |
|
Where are we on that? Is it still needed? |
|
This isn't high-priority, because it isn't actually fixing any bugs. This can wait until after the next release. |
2 participants
The function "el-get-as-symbol" is only used in interactive functions
that accept user input. All other functions assume packages are passed
and returned as symbols.
Assertions have been added to many functions that take packages or
lists of packages to enforce this. These can be removed later once we are sure that we're not passing any strings internally.