Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supply pre-built assets for easier packaging #493

Closed
clausecker opened this issue Jul 6, 2021 · 2 comments
Closed

Supply pre-built assets for easier packaging #493

clausecker opened this issue Jul 6, 2021 · 2 comments

Comments

@clausecker
Copy link

@clausecker clausecker commented Jul 6, 2021

I would like to make a FreeBSD port (package) of your nice project. Unfortunately one step in the build process involves using npm to build some assets. Node.js applications are notoriously hard to package because of the large amount of dependencies (all of which need to be manually kept track of and mirrored for reproducible builds) and that alone already makes it very hard for me to do the port.

Would it be possible for you to ship pre-generated asset files with the releases so I don't have to figure out these NPM problems? This would tremendously simplify the porting process. Apart from the assets, it seems to be just a straightforward Go project. Even the go-bindata step is simple (though I suppose you might replace that with native go:embed in the future).

@thebaer
Copy link
Member

@thebaer thebaer commented Jul 12, 2021

Thank you for taking an interest in this, @clausecker! We'll be happy to promote this package once it's available.

To your question, would the assets included in our official releases work? Or would you need them to be included in the repo? Ideally, we'd avoid committing them, so we can also avoid issues with things getting out of date.

Otherwise, glad to hear things are pretty straightforward. I would definitely like to switch us to go:embed in the future.

Lastly, just for some house keeping, I'm going to close this since it isn't a bug report. We can continue the discussion here, but in the future, our forum is the best place for these kinds of discussions!

@clausecker
Copy link
Author

@clausecker clausecker commented Jul 12, 2021

Hi @thebaer,

The assets included in the official releases would indeed work, but it's more hassle and requires a lot more data to be downloaded. A tarball with just the generated CSS files would be a good solution.

Ideally, we'd avoid committing them, so we can also avoid issues with things getting out of date.

A common strategy is to have a release branch with generated assets checked in that is merged into every release and has release tags. Thus, the assets only need to be updated on release and don't generate spurious changes during development. But I understand if you don't want to do this busywork.

Another difficulty I noticed is that getting good UX for the configuration is hard. Ideally, we would like to have files spread over three or four directories:

  • one directory for configuration files (e.g. /usr/local/etc/writefreely)
  • one directory for asset files that could be served by a reverse proxy (e.g. /usr/local/www/writefreely)
  • one directory for other files writefreely needs that should not be served by a reverse proxy (e.g. /usr/local/share/writefreely)
  • one directory for the database and key files; this one should be the only directory writable to writefreely (e.g. /var/db/writefreely)

Also, the working directory should not matter as that makes things harder when running the service as a daemon.

But right now it seems like most paths are hard coded and writefreely will only look for these files in the working directory. This makes things a bit harder for the port and forces us to break conventions (such as not mixing user-generated files with package-supplied files). I understand that some (but apparently not all?) of these paths can be overridden in the configuration file, but there is only one such file and if we have the user generate a configuration interactively, the user would have to be instructed to enter the right path which isn't very good UX.

Ideally there would be some sort of mechanism to have a configuration file (e.g. /usr/local/etc/default/writefreely.ini) with package-supplied default paths that is then completed by the user-supplied/config start generated configuration file. This way we could install a configuration file with the right paths and the user doesn't have to worry about getting these details right in his own configuration file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants