Timeline for How should I organize build instructions for third-party packages?
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 6, 2023 at 14:04 | comment | added | Doc Brown | @oliver: it depends how readable the build steps in some script are. Ideally, you have both, some script plus some documentation, probably at a slightly higher level of abstraction. Prose can help to understand what you have to do in a few months when your original buld script does not work any more because of a changed build process. | |
| Oct 6, 2023 at 9:08 | comment | added | oliver | Thanks for your input! Good point not to put too much effort into build automation for such packages. Regarding documentation: I like writing/having good docs, but I feel more comfortable writing the build steps in code rather than in prose (and I have most of the build steps already available in the existing Dockerfiles). So maybe I'll just create a repo for those 3rd-party build instructions, with a Dockerfile or shell script for each 3rd-party project; and then we can use that as documentation and for building, and adjust it for future releases. | |
| Oct 5, 2023 at 20:30 | comment | added | Doc Brown | ... that does not mean you cannot try to automate the process, too, as a bonus, but not "as much as possible", only "as much as sensible". | |
| Oct 5, 2023 at 20:28 | comment | added | Doc Brown | "packages change rarely - [...] so they don't need to be rebuilt often[...]. OTOH this also means that the builds should be automated as much as possible" - Sorry, but that is a fallacy. It actually means first and foremost you need to document the build steps thoroughly, so a rebuild can be done manually (and can be adapted more easily when the build steps change, as Thomas Owens' scetched above. When you just automate, and then the scripts fails for a new version, someone will have a pretty hard time to fix the automation. | |
| Oct 5, 2023 at 18:32 | comment | added | J_H | Author and add conda forge feedstock for the package. Encourage the upstream package author to maintain it. | |
| Oct 5, 2023 at 15:55 | comment | added | Thomas Owens♦ | Is automating the builds worth it? Let's say the third-party package is on v1.2 now. There's nothing that says that the build process for 1.3 or 2.0 will be the same. If any scripts or manual steps change, your automation will also change. And if you're only building a new version of this packages every few months, is the time to build and maintain automation for someone else's project in your own private space worth it? If they are open-source projects, perhaps it's more valuable to contribute improved build scripts to the projects and get community help to make everyone's build easier. | |
| Oct 5, 2023 at 15:21 | history | asked | oliver | CC BY-SA 4.0 |