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
As was briefly discussed in #358 the current tl command does a lot.
It has several "low level" commands, like checking a specific or building a specific file but it also has a higher level command (tl build). This resulted in the tl file being bigger than it probably should be, especially as it is written in lua rather than teal. It also means that not everyone agrees on what its scope is (or maybe just my idea doesn't align well with the rest, making me the problem :P ).
So, one possible solution is to split tl into 2. One being a simple compiler and is used for the low level commands like gen and check. The other has higher level commands and knows a lot more of the project. However, before people run off and make a higher level tool, lets first discuss on what features are wanted.
For me, I would like it if every teal project uses the same commands to get going.
init and new. These make new projects, init uses the current folder and new makes the folder for you. Ideally it can be given some template, though I am not sure what the best method for this is.
build same as the current tl build command. However I would love a few additions explained later.
add this simply adds a dependency to the project.
One of my biggest annoyances with other projects is that they often need to run special commands to get going and no project has the same naming scheme for these.
Rust somewhat limits this as it can automatically run code for you at build time using a build.rs file. However there are still places where it falls short.
First: Sometimes you only have to run something once when cloning a project, or only rarely. Think of installing dependencies or running database migrations. I would love it if teal projects have a default way to run a script that does this for you.
Second: Lua is used at a lot of places, which may not all accept the code in the same format. It would be great if users are able to have a script run automatically after building to transform the generated lua in whatever form they need.
So, the workflow would end up looking like
to create a new project, simply run init/ new
when having forked a project, the work flow is install to install the dependencies as well as run the init script (or whatever name we give it) that will setup the database and the like.
When we build/check the project, the gen_code script will also run if it needs to. This will be able to generate code at compile time, being useful to turn json schema's in actual .d.tl files and other tasks that we wouldn't mind being able to forget about.
Lastly after the project is done building, the after script will run. This will for example run luapak to pack the lua files into 1, zip it for use in love2d or do something else to make the code ready to be deployed on whatever system is needed.
I'm curious if the workflow that I would like to see is actually welcomed, as well as any flaws with it. I'm also curious what commands I missed that would be nice, as well as any other comments on this subject.
@euclidianAce feel free to place a comment on the current tl and tl-cli situation, or have that be its own discussion once everyone said what they would love to hear from a higher level tl command tool.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
As was briefly discussed in #358 the current
tl
command does a lot.It has several "low level" commands, like checking a specific or building a specific file but it also has a higher level command (
tl build
). This resulted in thetl
file being bigger than it probably should be, especially as it is written in lua rather than teal. It also means that not everyone agrees on what its scope is (or maybe just my idea doesn't align well with the rest, making me the problem :P ).So, one possible solution is to split
tl
into 2. One being a simple compiler and is used for the low level commands likegen
andcheck
. The other has higher level commands and knows a lot more of the project. However, before people run off and make a higher level tool, lets first discuss on what features are wanted.For me, I would like it if every teal project uses the same commands to get going.
init
andnew
. These make new projects,init
uses the current folder andnew
makes the folder for you. Ideally it can be given some template, though I am not sure what the best method for this is.build
same as the currenttl build
command. However I would love a few additions explained later.add
this simply adds a dependency to the project.One of my biggest annoyances with other projects is that they often need to run special commands to get going and no project has the same naming scheme for these.
Rust somewhat limits this as it can automatically run code for you at build time using a
build.rs
file. However there are still places where it falls short.First: Sometimes you only have to run something once when cloning a project, or only rarely. Think of installing dependencies or running database migrations. I would love it if teal projects have a default way to run a script that does this for you.
Second: Lua is used at a lot of places, which may not all accept the code in the same format. It would be great if users are able to have a script run automatically after building to transform the generated lua in whatever form they need.
So, the workflow would end up looking like
to create a new project, simply run
init
/new
when having forked a project, the work flow is
install
to install the dependencies as well as run theinit
script (or whatever name we give it) that will setup the database and the like.When we build/check the project, the
gen_code
script will also run if it needs to. This will be able to generate code at compile time, being useful to turn json schema's in actual.d.tl
files and other tasks that we wouldn't mind being able to forget about.Lastly after the project is done building, the
after
script will run. This will for example runluapak
to pack the lua files into 1, zip it for use in love2d or do something else to make the code ready to be deployed on whatever system is needed.I'm curious if the workflow that I would like to see is actually welcomed, as well as any flaws with it. I'm also curious what commands I missed that would be nice, as well as any other comments on this subject.
@euclidianAce feel free to place a comment on the current
tl
andtl-cli
situation, or have that be its own discussion once everyone said what they would love to hear from a higher leveltl
command tool.Beta Was this translation helpful? Give feedback.
All reactions