I have seen nothing to suggest the package library cares more about tallying than creating or investigating.
When you have something that is likely to be helpful to others and you are comfortable with allowing distribution, please, prime the pump. Later adopters often expect to lean on the package library, so ... when you are comfortable doing so, add to the library's core competancies. On Tuesday, July 14, 2015 at 5:11:46 AM UTC-4, Avik Sengupta wrote: > > This is probably entirely a matter of opinion, so here's my own.. > > There are many reason's to NOT register a package, but "not a fundamental > numerical ... component" is not one of them. I think it is perfectly fine > to register a domain specific library. So if that is your only concern, > please do register it. > > Technically, at the moment, you will need to register a package (and tag a > version) if any other package depends on it. However this restriction is > likely to go away in the future. > > A general rule I follow is that you should register a package if you think > anyone other than people you email directly can/should use your package. > This means two things. One, it allows people to find your package, makes is > discoverable. Two, it means that your package must have reasonable > documentation/tests for third parties to use it successfully. > > Regards > - > Avik > > On Tuesday, 14 July 2015 09:11:38 UTC+1, Christoph Ortner wrote: >> >> For a long time I had a question which seems closely related to this >> thread: https://groups.google.com/forum/#!topic/julia-users/621ta_jPdkA, >> so it seems as good a time as any to bring it up : >> >> I think the Julia package management is really wonderful, but what this >> question relates to is what types of packages should be actually be >> registered, and which should be just accessible using `clone`. More >> specifically: >> >> I am in the process of developing a library of Julia codes for my own >> group's research for now (molecular simulation), but with mid to long-term >> aim to make this a library that can be used for "real scientific work" by >> end-users (primarily materials modelling). But it is not a fundamental >> numerical simulation component like optimisation, linear algebra, ODE >> solvers, visualisation, ApproxFun.jl, etc, on which libraries like my own >> might depend. >> >> My own point of view was so far that such a library such not be a >> registered Julia package, to avoid the package repository getting unwieldy. >> But I would be interested in hearing other opinions. >> >> Thanks, >> Christoph >> >>
