Open pranasblk opened 6 years ago
as far as i can see, language detection is performed by github.com/linguist. I would say we need a more sophisticated detection strategy - the language is only one factor in finding the right pack. In this case, it's two steps: Detect Java -> Detect Build tool There might even be more steps, e.g. if you can can derive specifics of the run-time during the create.. (in java's case it's very simple, it always uses the "java" command). I saw in the commitlog that previously the packs did some detection, which was entirely replaced by linguist. Just thinking out loud - maybe a combination of both could be necessary - if multiple packs are eligible, the final decision could be deferred to the packs.
Gradle may be used for different languages in the same project e.g. one may create project with Java/Groovy or Java/Kotlin files java can be missing e.g. pure Kotlin project. Have you considered just detect Build System -> Set of languages (if required)?
It sounds like language -> build system flow is not flexible enough to detect typical JVM projects.
On Wed, May 2, 2018 at 11:02 AM, Johannes Brüderl notifications@github.com wrote:
as far as i can see, language detection is performed by github.com/linguist. I would say we need a more sophisticated detection strategy - the language is only one factor in finding the right pack. In this case, it's two steps: Detect Java -> Detect Build tool There might even be more steps, e.g. if you can can derive specifics of the run-time during the create.. (in java's case it's very simple, it always uses the "java" command). I saw in the commitlog that previously the packs did some detection, which was entirely replaced by linguist. Just thinking out loud - maybe a combination of both could be necessary - if multiple packs are eligible, the final decision could be deferred to the packs.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Azure/draft/issues/713#issuecomment-385834681, or mute the thread https://github.com/notifications/unsubscribe-auth/ADicckKtmcRmKAZ7Jym_xcgLTcYoh2SHks5tuQW2gaJpZM4TsLPr .
Right; linguist cannot determine the difference between a generic Python 2 app, a generic Python 3 app and a Django app, for example. Once we tackle #593 I think we can start to tackle these more "advanced" use cases for packs and address long-standing issues like #308 as well.
I'm a little concerned that this might end up being something a bit more than we can chew on our own, however, since we'll basically need to maintain a custom naive bayesian classifier that supports every language and every framework. Github stopped at the "detect a programming language" problem which works well for their use case, but it also prevented them from having to re-train their classifier every time a new framework release came out, which as you can imagine is on a significantly quicker release cycle than a programming language.
I agree that this does not have to be a problem that draft has to solves, at least not directly.
I see two options:
1) Do it in draft directly (that's how it's being done currently, we use a library but it's still done inside draft itself) 2) Delegate back to the detection to build packs; draft merely "orchestrates" the registration of build packs and calling them, as well as interpreting the result (e.g. what happens if multiple packs say they can "do the job").
I prefer 2) due to the reasons you mentioned: it's nothing we should do! Thinking forward, a naive implementation could just ask all registered build packs if they can "do it", and they answer with a probability or something like that. draft could just use the answer with the highest probablity.
I'm sure theres many more options but these come to my mind right now.
User's input would be valuable where autodeection fails e.g. select JDK version when runtime must be Java 8, but old code is Java 7
On Thu., 3 May 2018, 8:53 pm Johannes Brüderl, notifications@github.com wrote:
I agree that this does not have to be a problem that draft has to solves, at least not directly.
I see two options:
- Do it in draft directly (that's how it's being done currently, we use a library but it's still done inside draft itself)
- Delegate back the detection to build packs; draft merely "orchestrates" the registration of build packs and calling them, as well as interpreting the result (e.g. what happens if multiple packs say they can "do the job").
I prefer 2) due to the reasons you mentioned: it's nothing we should do! Thinking forward, a naive implementation could just ask all registered build packs if they can "do it", and they answer with a probability or something like that. draft could just use the answer with the highest probablity.
I'm sure theres many more options but these come to my mind right now.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Azure/draft/issues/713#issuecomment-386257434, or mute the thread https://github.com/notifications/unsubscribe-auth/ADicclUGQi-iYVq1eQjWtzdcsIhzKD_9ks5tuuG_gaJpZM4TsLPr .
But got Docker file: