David, I get that. Speaking personally, I adapt aspects of algorithms and snippets of coding insight from skilled practitioners -- not from fields. You are free to keep private or to make public any work you do. Maybe there will be few who use such a specialized package; there would be more who decide Julia is worth additional attention by virtue of the multiplicity of fields and deep specializations that it supports well. (if needed, imho).
On Tuesday, July 14, 2015 at 6:11:31 PM UTC-4, David Anthoff wrote: > > 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] <javascript:> [mailto: > [email protected] <javascript:>] *On Behalf Of *Josh Langsfeld > *Sent:* Tuesday, July 14, 2015 3:05 PM > *To:* [email protected] <javascript:> > *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:* [email protected] [mailto:[email protected]] *On > Behalf Of *Jeffrey Sarnoff > *Sent:* Tuesday, July 14, 2015 2:41 AM > *To:* [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 > > > >
