HFMU / HaskellFmu

The library package to include in order to develop an FMU with Haskell
Other
1 stars 0 forks source link

Production-ready hackage #13

Open CThuleHansen opened 5 years ago

CThuleHansen commented 5 years ago
trcc
When you submit to hackage, does it have to be "ready for production"?
harfangk has joined (~harfangk_@58.227.217.23)
trcc
sorry, wrong channel...
tdammers
"production ready" is a bit of a meme around here, because it doesn't really mean anything
tdammers
opinions as to what the acceptable code quality on hackage *should* be differ rather violently
tdammers
but in practice, it's mostly "free for all", for better or worse; it is considered good form to make sure at least that your package builds cleanly on all compiler versions it advertises to support though
merijn
trcc: It should at least be somewhat usable, imo
trcc
okay. Thakn you. Then I will wait. It is a library to implement simulation units, but it does not support all functions of the interface yet.
bo has joined (~Bo@195.39.233.28)
tdammers
in fact, the hackage folks regularly build all packages against a selection of GHC versions, and they may slap you if it fails to build against one of them that it says to support
tdammers
"does not support" how?
tdammers
as in, does it just not have those functions? or are the functions there, but stubbed out?
trcc
tdammers: there are about 20 functions of the c-interface, I have only implemented about 10
tdammers
oh, so you're FFI-wrapping some C API then?
trcc
But I think your answers has given me enough info to determine whenit is ready
trcc
yes
heptahedron has joined (~heptahedr@c-73-8-124-12.hsd1.il.comcast.net)
dhil has joined (~dhil@dhcp-90-108.inf.ed.ac.uk)
kuribas has joined (~user@ptr-25vy0i9b3mq1rfevmof.18120a2.ip6.access.telenet.be)
merijn
Some form of testing of the package would be good too before going on Hackage (see the Haskell-CI repo if you're too lazy to figure out how to set things up ;))
heptahedron
Does anyone know what happens if the action you pass to `alloca` throws an async exception?
trcc
merijn: Definitely. I will add that to my growing list of enhancements :D
merijn
heptahedron: Is this question "do I leak memory?" in disguise? :)
merijn
trcc: https://github.com/haskell-CI/haskell-ci
_kwstas has joined (~konstanti@ppp079167101152.access.hol.gr)
merijn
trcc: Script for auto-generating Travis-CI configs for cabal packages :)
_kwstas has left IRC (Remote host closed the connection)
kapil____ has joined (uid36151@gateway/web/irccloud.com/x-ksiyutxhynswnaxj)
heptahedron
merijn: Well I suppose, but if it's going to launch some nukes that would be nice to know as well lol
trcc
Amazing
trcc
thank you
CThuleHansen commented 5 years ago
trcc
When you submit to hackage, does it have to be "ready for production"? For example, my package is in version 0.1 currently
hvr
trcc: if you publish on hackage, it's because you want other people to start depending on it
hvr
trcc: and you're also committing to maintaining your releases on Hackage
hvr
trcc: and the version 0.1.* says very little about maturity imo
trcc
hvr: okay thank you. That clears it :)
hvr
there's tons of packages on hackage that are in 0.1.* or 0.2.* and are perfectly suitable for production
merijn
hvr: I don't suppose someone hacked supported for env variables into ~/.cabal/config yet, right?
hvr
merijn: not yet... it's still available for you to implement! :-D
merijn
hvr: I think the biggest hurdle is bikeshedding
merijn
I don't expect it to be very difficult, but last time you suggested we may not want arbitrary env variables
merijn
Personally I *really* want $HOME so I can probably version control my cabal file across hosts, but I dunno if we should just special case that or do things properly
hvr
trcc: you have at least two alternatives for packages which you don't yet consider ready for consumption: hackage package release candidates (that way you can e.g. easily host haddocks for them) or just keep it in a git repo (you can depend on packages living Git repos via cabal.project)
trcc
currently it is in git repo. I might do the hackage package release for the haddocks. I would like to start doing that. Thank you very much
hvr
trcc: you know how package candidates work?
trcc
hvr: no idea yet
hvr
trcc: it's quite simple, if you use `cabal upload` (assumign you have a reasonable recent cabal), it'll upload as a package candidate by default
hvr
it'll tell you the url
trcc
Woaw that is simpler than expected
trcc
it needs some user configuration though right?
hvr
then you simply build `cabal v2-haddock --haddock-for-hackage`
hvr
and `cabal upload -d ...` the resulting *-docs.tar.gz
hvr
then you have haddocks on the package candidate preview page for your package
trcc
Nice. Thank you very much
trcc
I will start writing some docs soon
hvr
at that point, you can preview how your package would look if it was published permanently to the primary package index forever
hvr
you can tweak your metadata
hvr
and reupload the same candidate version
merijn
hvr: btw, Hackage doesn't delete candidates when you publish, that's kinda annoying (and wasteful)
hvr
people can try it out by adding a line `packages: http://....` pointing to the .tar.gz on hackage
hvr
into their cabal.proejct
trcc
that sounds perfect
hvr
merijn: I know, it's one of the many tickets for the "complete the candidate feature" project =)
hvr
trcc: I never got to write a blogpost about it... but it'd definitely be worth writing one I guess :)
trcc
hvr: Once I have finished this adventure I will write a blog post with a title of something like: "First package on hackage - a beginners journey".. Or something more cheesy :P