Mixing
Why don't CTAN packages include build.lua?
Clash Royale CLAN TAG#URR8PPP
up vote
6
down vote
favorite
I notice that no packages on ctan include build.lua scripts, which would enable them to be installed using l3build.
I find it is now easier to build and install a package using l3build than manually processing the ins and dtx files and copying the derived files and documentation to the right locations.
So why don't we include the build.lua file in the ctan zip file?
(I know that most people would just wait until a package is in their distribution to install it. I'm just curious.)
ctan l3build
asked 7 hours ago
David Purton
6,9071731
add a comment |Â
up vote
6
down vote
favorite
I notice that no packages on ctan include build.lua scripts, which would enable them to be installed using l3build.
I find it is now easier to build and install a package using l3build than manually processing the ins and dtx files and copying the derived files and documentation to the right locations.
So why don't we include the build.lua file in the ctan zip file?
(I know that most people would just wait until a package is in their distribution to install it. I'm just curious.)
ctan l3build
asked 7 hours ago
David Purton
6,9071731
2
Presumably because noone else than the latex team uses or knows about them, plus they want users to update using the managers, hardly anyone updates by hand anymore
– daleif
1 hour ago
add a comment |Â
up vote
6
down vote
favorite
up vote
6
down vote
favorite
I notice that no packages on ctan include build.lua scripts, which would enable them to be installed using l3build.
I find it is now easier to build and install a package using l3build than manually processing the ins and dtx files and copying the derived files and documentation to the right locations.
So why don't we include the build.lua file in the ctan zip file?
(I know that most people would just wait until a package is in their distribution to install it. I'm just curious.)
ctan l3build
asked 7 hours ago
David Purton
6,9071731
I notice that no packages on ctan include build.lua scripts, which would enable them to be installed using l3build.
I find it is now easier to build and install a package using l3build than manually processing the ins and dtx files and copying the derived files and documentation to the right locations.
So why don't we include the build.lua file in the ctan zip file?
(I know that most people would just wait until a package is in their distribution to install it. I'm just curious.)
ctan l3build
ctan l3build
asked 7 hours ago
David Purton
6,9071731
asked 7 hours ago
David Purton
6,9071731
asked 7 hours ago
David Purton
6,9071731
asked 7 hours ago
David Purton
6,9071731
asked 7 hours ago
David Purton
6,9071731
6,9071731
2
Presumably because noone else than the latex team uses or knows about them, plus they want users to update using the managers, hardly anyone updates by hand anymore
– daleif
1 hour ago
add a comment |Â
2
Presumably because noone else than the latex team uses or knows about them, plus they want users to update using the managers, hardly anyone updates by hand anymore
– daleif
1 hour ago
2
2
Presumably because noone else than the latex team uses or knows about them, plus they want users to update using the managers, hardly anyone updates by hand anymore
– daleif
1 hour ago
Presumably because noone else than the latex team uses or knows about them, plus they want users to update using the managers, hardly anyone updates by hand anymore
– daleif
1 hour ago
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
5
down vote
There is nothing to stop you including build scripts in CTAN uploads: for example, in the past beamer used to have the Makefile on CTAN. However, a build script is not part of the package itself:, but is rather a convenience for the developer. (In the end, one can always extract a package and create documentation by hand.) Most notably, it's not usual to upload other 'support' material to CTAN, in particular test files, which are also part of the 'developer' files.
One can argue about the 'philosophical' aim of CTAN, but broadly it's always been about files for users. Additional material for developers has never really gone there. (For example, the sources for pdfTeX, etc., are not on CTAN.) Historically, users would take a .dtx/ins pair to install a package: today, almost all of them use TeX Live/MiKTeX, neither of which want build scripts. The small number of 'self-installing' users either are familiar with the classical route, or can be supported by a TDS-style zip for more complex packages.
Almost all code being actively developed has some kind of public source control nowadays. The type of user who is comfortable using a build script for a 'local install' is probably comfortable with a Git or SVN checkout, too. That lets them get the latest code, not necessarily what CTAN holds, in any case.
answered 1 hour ago
Joseph Wright♦
198k21545867
add a comment |Â
up vote
4
down vote
As Joseph writes build.lua and makefiles are for the development and not for CTAN (and I just removed the makefiles from the luaotfload upload for this reason). They can contain code and settings which are not suitable for a normal user installation like the call to local tools, or specific locations.
As an example in the build.lua of the lualibs package the install target "installs" the files in the repository of luaotfload. This makes it easy for me to run the online tests for luaotfload with synched lualibs files. It would be rather a pain to have to restrict the content of the build.lua to settings which makes sense in a normal user setup.
answered 22 mins ago
Ulrike Fischer
180k7285655
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
There is nothing to stop you including build scripts in CTAN uploads: for example, in the past beamer used to have the Makefile on CTAN. However, a build script is not part of the package itself:, but is rather a convenience for the developer. (In the end, one can always extract a package and create documentation by hand.) Most notably, it's not usual to upload other 'support' material to CTAN, in particular test files, which are also part of the 'developer' files.
One can argue about the 'philosophical' aim of CTAN, but broadly it's always been about files for users. Additional material for developers has never really gone there. (For example, the sources for pdfTeX, etc., are not on CTAN.) Historically, users would take a .dtx/ins pair to install a package: today, almost all of them use TeX Live/MiKTeX, neither of which want build scripts. The small number of 'self-installing' users either are familiar with the classical route, or can be supported by a TDS-style zip for more complex packages.
Almost all code being actively developed has some kind of public source control nowadays. The type of user who is comfortable using a build script for a 'local install' is probably comfortable with a Git or SVN checkout, too. That lets them get the latest code, not necessarily what CTAN holds, in any case.
answered 1 hour ago
Joseph Wright♦
198k21545867
add a comment |Â
up vote
5
down vote
There is nothing to stop you including build scripts in CTAN uploads: for example, in the past beamer used to have the Makefile on CTAN. However, a build script is not part of the package itself:, but is rather a convenience for the developer. (In the end, one can always extract a package and create documentation by hand.) Most notably, it's not usual to upload other 'support' material to CTAN, in particular test files, which are also part of the 'developer' files.
One can argue about the 'philosophical' aim of CTAN, but broadly it's always been about files for users. Additional material for developers has never really gone there. (For example, the sources for pdfTeX, etc., are not on CTAN.) Historically, users would take a .dtx/ins pair to install a package: today, almost all of them use TeX Live/MiKTeX, neither of which want build scripts. The small number of 'self-installing' users either are familiar with the classical route, or can be supported by a TDS-style zip for more complex packages.
Almost all code being actively developed has some kind of public source control nowadays. The type of user who is comfortable using a build script for a 'local install' is probably comfortable with a Git or SVN checkout, too. That lets them get the latest code, not necessarily what CTAN holds, in any case.
answered 1 hour ago
Joseph Wright♦
198k21545867
add a comment |Â
up vote
5
down vote
up vote
5
down vote
There is nothing to stop you including build scripts in CTAN uploads: for example, in the past beamer used to have the Makefile on CTAN. However, a build script is not part of the package itself:, but is rather a convenience for the developer. (In the end, one can always extract a package and create documentation by hand.) Most notably, it's not usual to upload other 'support' material to CTAN, in particular test files, which are also part of the 'developer' files.
One can argue about the 'philosophical' aim of CTAN, but broadly it's always been about files for users. Additional material for developers has never really gone there. (For example, the sources for pdfTeX, etc., are not on CTAN.) Historically, users would take a .dtx/ins pair to install a package: today, almost all of them use TeX Live/MiKTeX, neither of which want build scripts. The small number of 'self-installing' users either are familiar with the classical route, or can be supported by a TDS-style zip for more complex packages.
Almost all code being actively developed has some kind of public source control nowadays. The type of user who is comfortable using a build script for a 'local install' is probably comfortable with a Git or SVN checkout, too. That lets them get the latest code, not necessarily what CTAN holds, in any case.
answered 1 hour ago
Joseph Wright♦
198k21545867
There is nothing to stop you including build scripts in CTAN uploads: for example, in the past beamer used to have the Makefile on CTAN. However, a build script is not part of the package itself:, but is rather a convenience for the developer. (In the end, one can always extract a package and create documentation by hand.) Most notably, it's not usual to upload other 'support' material to CTAN, in particular test files, which are also part of the 'developer' files.
One can argue about the 'philosophical' aim of CTAN, but broadly it's always been about files for users. Additional material for developers has never really gone there. (For example, the sources for pdfTeX, etc., are not on CTAN.) Historically, users would take a .dtx/ins pair to install a package: today, almost all of them use TeX Live/MiKTeX, neither of which want build scripts. The small number of 'self-installing' users either are familiar with the classical route, or can be supported by a TDS-style zip for more complex packages.
Almost all code being actively developed has some kind of public source control nowadays. The type of user who is comfortable using a build script for a 'local install' is probably comfortable with a Git or SVN checkout, too. That lets them get the latest code, not necessarily what CTAN holds, in any case.
answered 1 hour ago
Joseph Wright♦
198k21545867
edited 1 hour ago
answered 1 hour ago
Joseph Wright♦
198k21545867
answered 1 hour ago
Joseph Wright♦
198k21545867
answered 1 hour ago
Joseph Wright♦
198k21545867
198k21545867
add a comment |Â
add a comment |Â
up vote
4
down vote
As Joseph writes build.lua and makefiles are for the development and not for CTAN (and I just removed the makefiles from the luaotfload upload for this reason). They can contain code and settings which are not suitable for a normal user installation like the call to local tools, or specific locations.
As an example in the build.lua of the lualibs package the install target "installs" the files in the repository of luaotfload. This makes it easy for me to run the online tests for luaotfload with synched lualibs files. It would be rather a pain to have to restrict the content of the build.lua to settings which makes sense in a normal user setup.
answered 22 mins ago
Ulrike Fischer
180k7285655
add a comment |Â
up vote
4
down vote
As Joseph writes build.lua and makefiles are for the development and not for CTAN (and I just removed the makefiles from the luaotfload upload for this reason). They can contain code and settings which are not suitable for a normal user installation like the call to local tools, or specific locations.
As an example in the build.lua of the lualibs package the install target "installs" the files in the repository of luaotfload. This makes it easy for me to run the online tests for luaotfload with synched lualibs files. It would be rather a pain to have to restrict the content of the build.lua to settings which makes sense in a normal user setup.
answered 22 mins ago
Ulrike Fischer
180k7285655
add a comment |Â
up vote
4
down vote
up vote
4
down vote
As Joseph writes build.lua and makefiles are for the development and not for CTAN (and I just removed the makefiles from the luaotfload upload for this reason). They can contain code and settings which are not suitable for a normal user installation like the call to local tools, or specific locations.
As an example in the build.lua of the lualibs package the install target "installs" the files in the repository of luaotfload. This makes it easy for me to run the online tests for luaotfload with synched lualibs files. It would be rather a pain to have to restrict the content of the build.lua to settings which makes sense in a normal user setup.
answered 22 mins ago
Ulrike Fischer
180k7285655
As Joseph writes build.lua and makefiles are for the development and not for CTAN (and I just removed the makefiles from the luaotfload upload for this reason). They can contain code and settings which are not suitable for a normal user installation like the call to local tools, or specific locations.
As an example in the build.lua of the lualibs package the install target "installs" the files in the repository of luaotfload. This makes it easy for me to run the online tests for luaotfload with synched lualibs files. It would be rather a pain to have to restrict the content of the build.lua to settings which makes sense in a normal user setup.
answered 22 mins ago
Ulrike Fischer
180k7285655
answered 22 mins ago
Ulrike Fischer
180k7285655
answered 22 mins ago
Ulrike Fischer
180k7285655
answered 22 mins ago
Ulrike Fischer
180k7285655
180k7285655
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f455613%2fwhy-dont-ctan-packages-include-build-lua%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
2
Presumably because noone else than the latex team uses or knows about them, plus they want users to update using the managers, hardly anyone updates by hand anymore
– daleif
1 hour ago