New package: Targets v0.1.0

[JuliaRegistrator]

• Registering package: Targets
• Repository: https://github.com/codedthinking/Targets.jl
• Created by: @korenmiklos
• Version: v0.1.0
• Commit: ca3d1ef5c83a930d8b6ada70b363bb0edf475851
• Reviewed by: @korenmiklos
• Reference: Register on General codedthinking/Targets.jl#3 (comment)

[github-actions]

Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human.

1. New package registration

Please make sure that you have read the package naming guidelines.

2. AutoMerge Guidelines are all met! ✅

Your new package registration met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

3. To pause or stop registration

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

Tip: You can edit blocking comments to add [noblock] in order to unblock auto-merging.

[korenmiklos]

The names Markets and Targets are sufficiently distinct so that they will not be mistaken. The name Targets is motivated by https://cran.r-project.org/package=targets. Please merge. [noblock]

[goerz]

Can I suggest ComputationalTargets? Just Targets might be a little too general [noblock]

[korenmiklos]

Can I suggest ComputationalTargets? Just Targets might be a little too general [noblock]

Targets is a much better name both because it is short and the usual name for these types of objects. GNU Make defines "targets", the corresponding R library is called "targets". [noblock]

[goerz]

Well, “short” is not something we optimize for. The naming guidelines emphasize “Err on the side of clarity, even if clarity seems long-winded to you.” Naming conventions in R or other languages are different from Julia and are not a good guide. When Targets popped up in the feed, I did not have any idea what this package would be about, which is a sign that the name is not descriptive enough. I could see myself coming around to Targets, but maybe we should get a second opinion.

[noblock]

[tecosaur]

Not to dogpile 😅, but from a glance at the package it does seem like a more verbose name might benefit this package. In particular I'm thinking of these two guidelines from https://pkgdocs.julialang.org/v1/creating-packages/#Package-naming-guidelines

• Err on the side of clarity, even if clarity seems long-winded to you.
• A less systematic name may suit a package that implements one of several possible approaches to its domain.

With that second point in particular, "targets" can only mean one thing in GNU Make, but there are both multiple ways of interpreting "Targets" in the context of Julia, and approaching this problem[1]. While this package is one interpretation/approach, it seems slightly presumptuous (to me at least) to claim the most generic name.

[1]: For example DataFlowTasks.jl does "targets" within a single function, and DataToolkit.jl does this for computed datasets.

[noblock]

[korenmiklos]

Thank you all for your valuable input on the package naming.

I'd like to make a case for retaining "Targets":

1. "Targets" is the established name in several similar domains (e.g., Make, R's targets package), not a convenience shortening.
2. It aligns with Julia's guideline on plural names for packages providing new types.
3. There doesn't seem to be a naming conflict with existing Julia packages.
4. Similar functionality in Julia is provided by the more complex packages DrWatson.jl, DataToolkit.jl, DataFlowTasks.jl, for example. These names are longer but not necessarily clearer to users.
5. "Targets" signals the package's simplicity and focused functionality: caching target = recipe(sources...) style function calls.

While it may appear broad, I believe it's sufficiently clear for the intended users and accurately reflects the package's scope. A longer name might not enhance clarity in this case.

I'm open to your thoughts if you feel I've overlooked any important considerations. Your expertise in the Julia ecosystem is invaluable.

Thank you again for your time and insights. [noblock]

[julianhinz]

As discussed by the OP, targets seems very clear to any R user or even user of make. Making the name longer, like the suggested ComputationalTargets, does not really help those that do not recognize targets alone either.
[noblock]

[goerz]

[noblock] I think I can come around to Targets, personally.

[goerz]

@korenmiklos Your first comment is was also blocking, so you'll have to edit that to allow the merge to go through [noblock]