You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From my point of view as a user it doesn't make much sense to have a "library infrastructure" generated by euler-manager. If I find some piece of code reusable, I will extract it to a library and require it myself. If not, a boilerplate library generated by the tool is just garbage.
It makes sense to have users extract their common components themselves especially since anything euler-manager generates would just be empty.
I think however that a standardized lib structure is necessary. Since some languages (like scala) will need the path to the lib directory to be in it's compilation command it's important to at least tell people where they should put their common code. Otherwise users would need to reconfigure already supported languages. The step from dictating where common code should go and generating empty boilerplate in that spot is pretty short.
For the time being it's better to simply remove the loading of lib/euler.* files.
Next step should be to make users aware of the lib structure and encourage them to put common code there.
Then (if I or anyone else gets around to it) generate and include boilerplate lib/euler* files.
Since we include
lib/euler.*
files in templates we should probably create these files when a person runs thenew
for the first time for that language.The text was updated successfully, but these errors were encountered: