New package: QuickTemplates v0.10.1

[JuliaRegistrator]

• Registering package: QuickTemplates
• Repository: https://github.com/Cglezf/QuickTemplates.jl
• Created by: @Cglezf
• Version: v0.10.1
• Commit: e02894cc03b831329c2ae00eb45ba605005c90e1
• Git reference: v0.10.1
• Description: Generador moderno de paquetes configurables en Julia 1.12+
• Release notes:

QuickTemplates.jl v0.10.1 - Initial Release

Modern Julia 1.12+ package generator (generic and scientific) with production-ready architecture.

Features: UUID idempotence, path traversal prevention, const memoization (~31x speedup), 105 tests, multiple dispatch extensibility.

Includes: CI, docs, formatter, dev workspace, DrWatson.jl support, Jupyter notebooks.

Architecture: ZERO_FALLBACKS principle, DRY helpers, fail-fast validation, type-stable multiple dispatch.

See [README](https://github.com/Cglezf/QuickTemplates.jl/blob/main/README.md) for usage.

[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.

[gdalle]

Hi again,
Following up on the discussion in #145852 (comment):

While PkgTemplates and BestieTemplate excel at general package generation, QuickTemplates fills a gap in the Julia ecosystem: it's the only template generator that safely handles registered packages (UUID preservation), optimizes for performance (31x speedup), and natively supports ML/DS workflows (DrWatson) — keeping the entire stack in pure Julia. Although designed with scientific computing in mind, QuickTemplates works perfectly for generic packages with all scientific features disabled by default.

• Doesn't BestieTemplate also preserve existing packages, since it is made to be upgradeable?
• Why does performance matter when creating a new package? Even if it takes a few seconds, it is a task that is done at most once a day, right?
• DrWatson configuration sounds like a plugin that could be added to both PkgTemplates and QuickTemplates?

In addition, I have a few other remarks:

• QuickTemplates is a bit too generic as a name, if you do want to register the package, I'd suggest adding a word that refers to package creation (users could believe you're providing other kinds of templates)
• The README should probably be in English if you want a wide audience.
• Is the package entirely vibe-coded?

Normally I would be less picky, but package generators are tricky to get right and deserve a unified approach on which the community agrees, otherwise beginners will get confused by the variety of options. Unless there is a clear advantage compared to both PkgTemplates and BestieTemplate, I would strongly suggest contributing to those instead.

[Cglezf]

Registry Reviewer Response

Thank you for the thoughtful feedback on ecosystem fragmentation concerns. I appreciate your time reviewing this submission.

Acknowledging Errors

You're absolutely right on several points, thats was the new changes from 0.9.x to 0.10.x, not of the all the package, my mistake:

1. UUID preservation - BestieTemplate already handles this via upgradeable design. I incorrectly positioned this as unique.
2. Performance claims - 31x speedup is engineering detail, not user-facing value for one-time package generation.
3. DrWatson as plugin - Could theoretically be added to existing tools.

These were errors stemming from incomplete research before submission.

Refined Value Proposition

After reflection, QuickTemplates serves a specific niche: a learning-friendly template for Julia newcomers in data science who want:

1. Pure Julia stack - No Python/Copier dependencies for simpler mental model
2. Persistent configuration - One-time setup, no re-entering name/email/GitHub for every package (vs. BestieTemplate's interactive prompts each time)
3. "Just works" philosophy - Simple workflow with single config.toml vs. multiple configuration files and technical setup
4. Architectural transparency - Readable source as educational resource
5. Data science patterns out-of-box - DrWatson for reproducible research, Result types for pipeline error handling, tolerance testing for numerical validation
6. Complete infrastructure setup - CI, multiple workspaces, modern Julia 1.12+ patterns so data scientists focus on experiments, not tooling

This is not a replacement for PkgTemplates/BestieTemplate - it's a learning resource with opinionated data science workflow defaults and minimal-friction workflow for individual researchers.

Workflow Philosophy Differences

Where QuickTemplates differs is workflow approach:

BestieTemplate: Interactive prompts every time, re-enter name/email/GitHub for each package, multiple config files (copier.yml, answers), technical/power-user oriented.

QuickTemplates: One-time setup_identity() creates ~/.config/QuickTemplates/.env, reusable across all packages, single config.toml per project, "just works" and DRY philosophy.

Different target audiences: BestieTemplate for teams with complex CI/CD, QuickTemplates for individual data scientists who value simplicity and minimal friction.

On "Vibe-Coding"

The architecture is human-designed (ZERO_FALLBACKS, sub-structs composition, multiple dispatch extensibility), but I used AI for:

• Code review to catch Python/JavaScript anti-patterns
• Documentation translation
• Pattern consistency

I'm transparent about this because I'm learning Julia (~6 months from Python/R backgrounds). I don't yet have expertise to contribute confidently to mature codebases like PkgTemplates/BestieTemplate without introducing anti-patterns.

Development Status

Current: Package in active development, submitted for community feedback. This is a learning project from someone with postgraduate background in data science who recognizes Julia's tremendous potential yet observes its underutilization in practical workflows.

Post-collaboration: Version 1.0 will include comprehensive Documenter.jl documentation explaining architectural patterns (ZERO_FALLBACKS with technical details, sub-structs composability, multiple dispatch extensibility, security validation).

Path Forward

I'm open to guidance:

Option A: Rename and Position as Learning Resource

• Rename to DataPkgGen.jl, DataPkgTemplate.jl, or QuickPkgTemplate.jl
• Explicitly document as educational/data science workflow-focused
• Recommend PkgTemplates/BestieTemplate for general production use

Option B: Extract and Contribute Upstream

• Result.jl module as standalone package
• Security validation helpers
• DrWatson templates as PkgTemplates plugin

Option C: Personal Use Only

Do not register in General.

Translation Completed

I've translated core documentation to English:

• README.md - Architecture overview and comparisons
• README.es.md - Spanish version

Key architectural patterns documented directly in README sections for accessibility without doc generation.

Closing

If this niche isn't valuable enough to justify ecosystem fragmentation, I'm receptive. My primary goal is contributing to the Julia data science ecosystem as a practitioner learning best practices - whether through a focused package, upstream contributions, or using existing tools more effectively.

I welcome your perspective after this clarification, and I'm particularly interested if features like Result types integration or DrWatson workflow patterns would be valuable contributions to PkgTemplates or BestieTemplate.

Thank you for holding the bar high for the Julia registry.

---

Sources:

• PkgTemplates.jl
• BestieTemplate.jl

[goerz]

I agree with all the points raised in #145883 (comment), and I'd also like to explicitly point out the guidelines for LLM usage in registered packages. Your response in #145883 (comment) looks LLM-generated, which would be considered inappropriate here. I understand there may a be it of a language barrier, and you may not be feeling as confident with writing in English. It is fine to use LLMs for translation in such a situation, but please limit the LLM usage to translation only. If that response was indeed handwritten and simply translated, I apologize in advance (but it never hurts to be clear about our expectations here, regarding LLMs)

Don't take this a discouragement, but my recommendation would be to hold off on this registration:

I'm learning Julia (~6 months from Python/R backgrounds). I don't yet have expertise to contribute confidently to mature codebases like PkgTemplates/BestieTemplate without introducing anti-patterns. […] My primary goal is contributing to the Julia data science ecosystem as a practitioner learning best practices

As someone learning the language, I don't think you have enough experience yet to really encapsulate "best practices" in a package like this. Although I think writing this package is a great way for you to engage with possible best practices and develop some ideas! But I would recommend going with

Option C: Personal Use Only

Do not register in General.

for now. Registration in the General registry is actually a bit less important than many people (especially newcomers) think: it is perfectly fine to work with unregistered packages. Registration is only absolutely essential when a package needs to serve as a dependency for another registered package. For this package, as an "end user tool", that's not really something that would come into play at all. So I wouldn't register this until it's fairly mature and gets some traction… If you start getting requests for registration from users, that might be a time to reconsider.

In the meantime, I would encourage you to keep working on this and also engage with the community on Discourse. That would be a great place to learn more about the relevant development practices, and also to get wide feedback on the ideas encapsulated in your package

[Cglezf]

Thanks for the detailed feedback—I really appreciate the clarity.

You're right to call it out about the LLM usage. I did write the responses myself, but used AI to translate and check for clarity since English isn't my first language. The AI did flag some Julia idioms I got wrong (coming from Python habits), which I corrected. I'll be more careful to keep it truly translation-only. I know my writing can sound overly structured—it's a bad habit from years of academic papers and data science projects documentation .

I hear you on the registration timing. Maybe I'm being naive here, but coming from Python/R, it felt like there was a gap in resources for profiles like mine, but maybe I just haven't found them yet. I might be projecting my own experience as someone new to the ecosystem.

One thing I'm genuinely curious about though—how do packages actually get that initial traction if they're not discoverable through the registry? Is it mainly through Discourse posts, or personal networks, or something else I'm missing as a newcomer?

Anyway, I'm here to learn and contribute properly. If my approach is wrong, I'd rather know now. Thanks again for taking the time to review this—the feedback has been valuable.

[goerz]

coming from Python/R, it felt like there was a gap in resources for profiles like mine, but maybe I just haven't found them yet.

I feel like it's important to point that there are strong cultural differences between the Julia community and other communities like Python/R. There is much more of a collective ownership of the ecosystem in Julia. Thus, unlike PyPI, the General registry isn't just a free-for-all — although it is not as strictly reviewed as CRAN. Also, we very strongly encourage contributing to existing solutions, like PkgTemplates and BestieTemplate. It is better to have a few active projects with multiple contributor than to have a lot of registered packages, many of which then end off half-baked or abandoned.

how do packages actually get that initial traction if they're not discoverable through the registry?

I'm not sure he registry adds very much in terms of discoverability. Personally, I'd say Discourse and Slack are the best way to engage with the community. On top of that, the usual social media, YouTube, and, of course, JuliaCon (which is a bit of a high bar)