Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
remove lib/.nosearch #85
This file was originally added to prevent a bundled
I noticed that you require sly libraries using
I came very close to merging this this, but now I'm thinking I shouldn't.
It won't work. And I intend for a MELPAless install to remain possible.
So, to summarize: if
So I prefer to have this. The libs in
For another perspective, some of those
Sorry for the long delay!
Two elements instead of one isn't really such a big deal I would say. Unless of course every package does it. But that isn't the case.
That's because what you are doing here is highly unusual. Among the > 4500 packages on the Emacsmirror I think
What most users do is to put all libraries in a singe directory. Very often that's just the top-level directory, or when a subdirectory is used, then
There's one exception to that convention: "bundled" libraries should be put into a separate directory, but let's discuss that in the other issue I opened.
Your argument about best practices has value, but remind me again of the problem that arises with the current way i organize code.. Is it just the requires or is emacsmirror impacted in any practical way too?
Lib should indeed be elisp and slynk should be perhaps lisp. But then there is contrib as well... I'd rather not change it unless there is a good practical reason...
As part of the Emacsmirror I maintain a package database which can be queried using
The database contains among other things automatically extracted dependency information about all mirrored packages. Sometimes there are issues like feature conflicts or unsatisfied dependencies. My tool (primarily
The Emacsmirror is affected by various
And with regards to
That doesn't have to be changed. It isn't uncommon to have e.g.
Just noticed you have also checked in
I wasn't aware of epkg.el but why can't you make an exception to tour .nosearch heuristic? Being an heuristic, it is bound to fail sometimes. I'm sure you can modify epkg.el with a few lines to improve that heiristic with a list of exceptions, like if there was an
The hyperspec issue is a different matter. I'll answer separately.