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

pack install doesn't run postinstall #248

Open
joelberkeley opened this issue May 16, 2023 · 16 comments
Open

pack install doesn't run postinstall #248

joelberkeley opened this issue May 16, 2023 · 16 comments
Labels
expected behaviour Described behaviour is what it's meant to be feature request Request for new functionality

Comments

@joelberkeley
Copy link
Contributor

joelberkeley commented May 16, 2023

If I pack install spidr, pack doesn't run postinstall. On the other hand, if I run pack build spidr.ipkg locally, it does run postbuild.

My script reads a file and prints some output, so it's obvious when it runs

@joelberkeley joelberkeley changed the title pack install spidr doesn't run postinstall pack install doesn't run postinstall May 16, 2023
@joelberkeley
Copy link
Contributor Author

I've also checked and idris2 --install spidr.ipkg run the postinstall script

@joelberkeley
Copy link
Contributor Author

joelberkeley commented May 16, 2023

since my postinstall mainly prints to stdout, it's possible that pack install is running postinstall but is supressing the output

@stefan-hoeck
Copy link
Owner

since my postinstall mainly prints to stdout, it's possible that pack install is running postinstall but is supressing the output

Can you try running with pack --log-level debug and see whether the expected output is printed? Also, as a default, pack runs idris2 --install-with-src internally instead of just idris2 --install. Could you please verify if with this command the postinstall hook is being run?

@joelberkeley
Copy link
Contributor Author

pack --log-level debug does the trick. Haven't tried the others yet

@joelberkeley
Copy link
Contributor Author

I also just verified that pack install without --log-level debug does run postinstall - I used it to create a file. So it's definitely just suppressing output

@joelberkeley
Copy link
Contributor Author

and yes, idris2 --install-with-src spidr.ipkg does run postinstall

@stefan-hoeck
Copy link
Owner

I also just verified that pack install without --log-level debug does run postinstall - I used it to create a file. So it's definitely just suppressing output

Yes, this is the expected behavior. We want to suppress the output from idris2 --install (but not from idris2 --build), because it clutters the application log with lots of messages about what files get copied where. Hence, the output of postinstall-hooks will also be suppressed.

@stefan-hoeck
Copy link
Owner

I'm closing this, at it describes expected behavior. Feel free to reopen if you want to further discuss this issue.

@joelberkeley
Copy link
Contributor Author

Can I ask why this is the intended behaviour? Why is it different from postbuild?

@joelberkeley
Copy link
Contributor Author

btw I don't seem to have the option to reopen the issue

@stefan-hoeck stefan-hoeck reopened this May 16, 2023
@stefan-hoeck
Copy link
Owner

Can I ask why this is the intended behaviour? Why is it different from postbuild?

The difference is not about the postbuild and postinstall hooks but that - as a default - we want the output of idris2 --build to be printed, because this shows us the progress of building a library, which typically takes several seconds. On the other hand, we don't want to print the output of idris2 --install, because it totally clutters stdout with the paths of what files get copied where during installation. This might be interesting for debugging, but the average user should not be bothered with this, especially since idris2 --install is more or less instantaneous.

So, internally, pack runs the two commands separately: First idris2 --build with the output being logged at log level build, and and then idris2 --install-with-src with the output being logged at log level debug. As a - possibly unfortunate - side effect, the output of postbuild hooks gets also logged at log level build while postinstall gets logged at log level install.

As an alternative we could try and filter the output of idris2 --install and logging the rest at log level build, but I'm not sure if this would make things even less predictable. Another alternative would be to adjust idris2 in such a way that it allows us the silence the file copying spam.

@joelberkeley
Copy link
Contributor Author

joelberkeley commented May 16, 2023

OK, thanks for the detailed explanation. I don't want to take up your time over this detail, and am happy to just use postbuild for now. However, I'm also interested in working out the right way to do this. If you are too, here's what I'm doing:

My postinstall simply prints installation instructions appropriate for the specific commit. The instructions just download files and edit shared library links. I have a few reasons for printing the instructions rather than executing them, but eventually I may just execute them, so postinstall (or preinstall) definitely sounds like the right place for that.

@joelberkeley
Copy link
Contributor Author

joelberkeley commented May 16, 2023

I like the idea of idris --install logging at different levels so it's possible to silence some parts but not others. I definitely think the output of postinstall and the list of which files were copied where could be at different logging levels. I guess it depends on how library authors use postinstall and postbuild, which could contain useful stuff, like my instructions, but it could also contain a whole load of noise.

@buzden
Copy link
Collaborator

buzden commented May 16, 2023

As a workaround (if it is appropriate for you), you can print instructions to stderr in your postinstall. In this case, they won't be suppressed by pack.

@joelberkeley
Copy link
Contributor Author

thanks. For now I've used postbuild

@joelberkeley
Copy link
Contributor Author

joelberkeley commented May 17, 2023

I feel it's worth addressing this somehow but don't need it myself so don't need the issue to stay open

@buzden buzden added expected behaviour Described behaviour is what it's meant to be feature request Request for new functionality labels Jul 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
expected behaviour Described behaviour is what it's meant to be feature request Request for new functionality
Projects
None yet
Development

No branches or pull requests

3 participants