My stuff is in a VERY small field where we know each other personally. New people will look at what the few people around have done before and will find it via that way. At least for my stuff I have no need for advertising either via google or a package registry.
From: [email protected] [mailto:[email protected]] On Behalf Of Josh Langsfeld Sent: Tuesday, July 14, 2015 3:05 PM To: [email protected] Subject: Re: [julia-users] Re: Which Packages Should be Registered? Christoph and David, If you want your package to be useful to the world, how should new users in your domain find it? With a Google search? I'm of the same opinion of Jeffrey that anything that could be helpful to others should be registered in some capacity. Besides making it easier to find, it also provides a strong incentive for the owner(s) to be more diligent about the content. For that reason, I'm also skeptical about allowing dependencies on non-registered packages. You said registering seemed like a lot of hassle but was there anything else besides the naming difficulties? That seems surmountable but maybe it would be a good example for proposing something like domain namespaces or directories so we can start adding packages with jargony names. On Tuesday, July 14, 2015 at 4:45:53 PM UTC-4, David Anthoff wrote: I am in the same position as the original author: I have a domain specific package that is of interest to a small number of people that work in the same field as I do, but certainly of no interest to anyone else. I tried to register it at some point, but then I ran into questions whether the name of the package conformed to the naming guidelines. It didn’t, but in my case I am actually more concerned whether the name plays well with the small number of domain experts that I work with than whether it plays well with the Julia rules. I the end I decided to just no register it, seemed a lot less hassle. I also think at the end of the day it is perfectly fine (and maybe even better) to have packages like mine not registered. I think there are a couple of ways in which this scenario could be improved: a) if one could use Pkg.add instead of Pkg.clone for such packages. My sense is that the distinction between the two might be going away at some point in any case. b) if there was versioning of unregistered packages. In my mind it would be enough to just use git tags for that. For now I just develop on a next branch and make sure master is always on a released, stable commit. c) if one could take dependencies on unregistered packages in REQUIRE. My sense is that these things are going to happen at some point in any case, at least if I read the discussion re packages correctly. From: <javascript:> [email protected] [mailto: <javascript:> [email protected]] On Behalf Of Jeffrey Sarnoff Sent: Tuesday, July 14, 2015 2:41 AM To: <javascript:> [email protected] Subject: [julia-users] Re: Which Packages Should be Registered? 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
