Skip to content

add HyperClovaX Vision#44314

Open
jp1924 wants to merge 126 commits into
huggingface:mainfrom
jp1924:feat/hcx-seed-32b
Open

add HyperClovaX Vision#44314
jp1924 wants to merge 126 commits into
huggingface:mainfrom
jp1924:feat/hcx-seed-32b

Conversation

@jp1924

@jp1924 jp1924 commented Feb 27, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Hello, Transformers team!

I submitted a PR to add naver-hyperclovax/HyperCLOVAX-SEED-Think-32B (hereafter HCX), developed by the Korean IT company Naver while executing the government's national AI model project.

The HCX code was written based on Transformer 4.52.4, leading to the following issues:

  1. Being based on an outdated Transformer model prevents the application of the latest training optimization techniques supported by Transformer 5.0.0 (e.g., sequence parallelism).
  2. The use of some deprecated code or features may cause unexpected bugs in the latest Transformer version.
  3. The modeling code was overly complex, reducing debugging and development convenience. Additionally, experimental code used during model creation remained untouched.

Moving to Transformer 5.0.0 significantly improved the readability and development convenience of the modeling code. We aim to leverage this to add the HCX model to transformers.

Before submitting

  • This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
  • Did you read the contributor guideline,
    Pull Request section?
  • Was this discussed/approved via a Github issue or the forum? Please add a link
    to it if that's the case.
  • Did you make sure to update the documentation with your changes? Here are the
    documentation guidelines, and
    here are tips on formatting docstrings.
  • Did you write any new necessary tests?

Who can review?

@zucchini-nlp @yonigozlan @molbap

@jp1924 jp1924 changed the title add HyperCLOVAX Vision add HyperClovaX Vision Feb 27, 2026
@jp1924

jp1924 commented Feb 27, 2026

Copy link
Copy Markdown
Contributor Author

When I ran the test in my environment, hcx test ran normally without any failures.
The process for adding a model will likely proceed like this:

  • First, fix all the comments you guys added in the modeling part.
  • (Optional) Add modular code.
  • Once the modeling code work is nearly complete, write the docstrings.
  • Then apply the style.

I think the work will proceed in this manner?

@jp1924

jp1924 commented Feb 27, 2026

Copy link
Copy Markdown
Contributor Author

Hmm... In my environment, torch_compilable_check passes normally, but it fails in this test. I think I need to look into this issue further.

@ArthurZucker

Copy link
Copy Markdown
Collaborator

Yep don't worry we'll fix this one on main!

@zucchini-nlp zucchini-nlp left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @jp1924, thanks a lot for the PR!

I think we need to move all the code to modular file first, since there is a lot of copied stuff from other models. I left you comments below about where exactly can copy from. Ping me for another review when the modular is ready

Comment thread src/transformers/models/hyperclovax_vision/configuration_hyperclovax_vision.py Outdated
Comment thread src/transformers/models/hyperclovax_vision/configuration_hyperclovax_vision.py Outdated
Comment thread src/transformers/models/hyperclovax_vision/configuration_hyperclovax_vision.py Outdated
Comment thread src/transformers/models/hyperclovax_vision/configuration_hyperclovax_vision.py Outdated
Comment thread src/transformers/models/hyperclovax_vision/configuration_hyperclovax_vision.py Outdated
Comment thread src/transformers/models/hyperclovax_vision/modeling_hyperclovax_vision.py Outdated
Comment thread src/transformers/models/hyperclovax_vision/modeling_hyperclovax_vision.py Outdated
Comment thread tests/models/hyperclovax_vision/test_modeling_hyperclovax_vision.py Outdated
Comment thread tests/models/hyperclovax_vision/test_modeling_hyperclovax_vision.py Outdated
Comment thread tests/models/hyperclovax_vision/test_processing_hyperclovax_vision.py Outdated

@vasqu vasqu left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few comments I think we can improve on especially re modular. But I don't think it's anything major

I responded on the comment re model type as well btw, it's a bit hard because not being able to use auto is kind of a big deal

Comment thread docs/source/en/model_doc/hyperclovax_vision_v2.md Outdated
# Use processor.tokenizer.apply_chat_template for video inputs.
# processor.apply_chat_template rewrites image_url to image before the
# template runs, which breaks HCX's extension-based video detection.
text = processor.tokenizer.apply_chat_template(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is weird, why are we even using image url --> shouldnt it be video url to properly distinguish between img/video? cc @zucchini-nlp

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

huh, didn't see it. I believe related ti how the jinja template is saved on the hub

This indeed looks weird, lets' ping the Naver team to change model-type/jinja/etc or ask them to host a non-remote version. @jp1924 , when you are done passing over comments, could you list the things we need to change on the hub and ping @ (bigshanedogg). We need to either push directly to the existing repo or upload a new repo with {{MODELNAME}}-hf suffix

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#44314 (comment)
You can check the details via this link.
Sharing the text below as well since the link is dead.

I added this logic because video handling for HCX is broken on recent versions of transformers.

If you look at HCX's chat_template.jinja, it handles image/video differently from most models.  
Models like `Qwen2_5_vl` or `VideoLLaMA3` expect multimodal items in a normalized form such as `{"type": "image"}` or `{"type": "video"}`.  
HCX, however, uses `{"type": "image_url", "image_url": {"url": "video.mp4"}}` and `{"type": "image_url", "image_url": {"url": "image.png"}}`, then branches by file extension inside the template.

In newer transformers, this block rewrites image_url into image:
https://github.com/huggingface/transformers/blob/2da00a3cec88fac160d481406e7961cf59472894/src/transformers/processing_utils.py#L1792-L1799

Because of that rewrite, HCX's image_url-based branch no longer triggers correctly. As a result, even when a video is provided, it gets rendered like plain text:

    ```
    >>> from transformers import AutoProcessor
    >>> processor = AutoProcessor.from_pretrained("naver-hyperclovax/HyperCLOVAX-SEED-Think-32B", trust_remote_code=False)
    You are using a model of type `vlm` to instantiate a model of type ``. This may be expected if you are loading a checkpoint that shares a subset of the architecture (e.g., loading a `sam2_video` checkpoint into `Sam2Model`), but is otherwise not supported and can yield errors. Please verify that the checkpoint is compatible with the model you are instantiating.
    >>> video_messages = [
    ...     {
    ...         "role": "user",
    ...         "content": [
    ...             {"type": "image_url", "image_url": {"url": "https://huggingface.co/datasets/hf-internal-testing/sam2-fixtures/resolve/main/bedroom.mp4"}},
    ...             {"type": "text", "text": "What is shown in this video?"},
    ...         ],
    ...     }
    ... ]
    >>> text = processor.apply_chat_template(video_messages, tokenize=False, add_generation_prompt=True)
    >>> text
    '<|im_start|>user\n\nWhat is shown in this video?<|im_end|>\n<|im_start|>assistant\n<think>\n\n</think>\n\n'
    >>> video_messages
    [{'role': 'user', 'content': [{'type': 'image', 'url': 'https://huggingface.co/datasets/hf-internal-testing/sam2-fixtures/resolve/main/bedroom.mp4'}, {'type': 'text', 'text': 'What is shown in this video?'}]}]

    ```

If it were working correctly, the output should include the video MIME and video tokens, e.g. mime_start / video_aux_start / VIDEO_PAD, not the plain-text-only prompt above.

bigshanedogg The current multimodal input contract in naver-hyperclovax/HyperCLOVAX-SEED-Think-32B is non-standard.  
I opened a Hub discussion/PR to update chat_template.jinja so it aligns with current processor behavior:
https://huggingface.co/naver-hyperclovax/HyperCLOVAX-SEED-Think-32B/discussions/12

zucchini-nlp Until that template update is merged, we need to keep this compatibility code in this PR.  
I'll follow up again once we have a decision on the Hub-side template PR.


## Notes

- HyperCLOVAX Vision V2 uses a unique media input format. Both images and videos are specified using `{"type": "image_url", "image_url": {"url": "..."}}`. The processor and chat template distinguish images from videos by file extension (`.mp4`, `.avi`, `.mov`, `.mkv`, `.webm`, `.flv`, `.wmv`, `.m4v` are treated as video; everything else is treated as image).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok this is the explicit change, imo would maybe make sense to have a different chat template if possible. This really is weird

```

> [!WARNING]
> Video input via `processor.apply_chat_template` is currently broken. Recent Transformers versions rewrite `image_url` entries to `image` before the chat template runs, so the video-detection branch in HCX's template never triggers and video inputs are silently dropped. As a workaround, use `processor.tokenizer.apply_chat_template` to render the prompt text, then pass the video path separately to `processor(...)`. See [this review comment](https://github.com/huggingface/transformers/pull/44314#discussion_r3008382827) for details.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the review comment is closed, cant load via url it seems

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've reopened the comment.

Comment thread docs/source/en/model_doc/qwen2_5_vl.md
Comment thread src/transformers/models/hyperclovax_vision_v2/modular_hyperclovax_vision_v2.py Outdated
Comment on lines +266 to +269
@auto_docstring
class HCXVisionV2ForConditionalGeneration(HCXVisionV2PreTrainedModel, GenerationMixin):
accepts_loss_kwargs = False
_tied_weights_keys = {"lm_head.weight": "model.language_model.embed_tokens.weight"}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry but I don't really agree, we can inherit a lot from exaone 4.5 here

  1. the flags are the same
  2. init is the same (minus the vocab size but we can just call the forward similarly to get the vocab size)
  3. get img/video features are identical (only wrappers, agree base mode is different but it doesnt matter here)

The difference can be easily overwriten as is (forward/prepare for generate). And we can ignore the methods we don't need with def method(...): raise AttributeError()

Currently it seems we miss a few utilities as expand input is missing which will cause failures with beam search iirc

Comment thread src/transformers/models/hyperclovax_vision_v2/modular_hyperclovax_vision_v2.py Outdated
Comment thread src/transformers/models/hyperclovax_vision_v2/modular_hyperclovax_vision_v2.py Outdated

@bigshanedogg bigshanedogg left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the changes — I've reviewed them.

The main thing I took away is that the model_type in config.json needs to be updated. If my understanding from the comment above is correct, that should be all that's needed for this part:
#44314 (comment)

I also have two minor suggestions.

First, would it be possible to rename the classes from HCX to HyperCLOVAX?
This would also be more consistent with the naming convention used in the related preceding PR for the HyperCLOVAX bare LM — e.g., HyperCLOVAXVisionV2Config.

Second, regarding the processor updates: in previous models, image_processing_*.py and video_processing_*.py are split into separate files, with processing_*.py acting as the unified entry point. We were planning to push a new version of the processor for hyperclovax_vision_v2 to the hub following the same structure, and I was wondering if it might make sense to include that update in this branch as well.
(ref: https://github.com/huggingface/transformers/tree/main/src/transformers/models/qwen2_vl)

Please feel free to share any feedback on the minor points.

As for the config.json change, based on my understanding only the model_type needs to be updated to "hyperclovax_vision_v2" — could you double-check this? Once confirmed, I'll go ahead and update it on the hub.

@vasqu vasqu left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry most of the team was off for a few days!

Responding now:

  1. I think the rename is reasonable (HCX -> HyperCLOVAXVisionV2) cc @jp1924
  2. Hmm, not sure I can follow the processor update but in general yes, we would likely need to update the code as well. I would not update qwen2 vl itself - if there are changes needed for this model, I'd rather have a custom version that builds upon that (that's what modular is for). It kind of relates to #44314 (comment) where we want to change the chat template to properly separate between images and videos.
  3. Yes, exactly the model type on the hub needs to be corrected, e.g. see https://huggingface.co/naver-hyperclovax/HyperCLOVAX-SEED-Think-32B/blob/main/config.json#L25 where we have "model_type": "vlm", but need to sync with here

Ideally, we try to sync with this PR so that we can avoid the remote code and directly move to the "native" version. Meaning, we keep these changes to a PR and only merge them when everything is ready here, wdyt? @bigshanedogg @jp1924

jp1924 and others added 8 commits May 26, 2026 14:26
…vax_vision_v2.py

Co-authored-by: Anton Vlasjuk <73884904+vasqu@users.noreply.github.com>
Co-authored-by: Anton Vlasjuk <73884904+vasqu@users.noreply.github.com>
- Updated class names and configurations to follow the new naming convention (e.g., HCXVisionV2 to HyperCLOVAXVisionV2).
- Enhanced documentation strings for clarity and consistency.
- Adjusted default token IDs for image and video processing.
- Removed unnecessary attributes and methods related to token type IDs and temporal RoPE.
- Improved the processor's handling of multimodal inputs, including image and video tokens.
- Updated test cases to reflect the new class names and configurations.
@jp1924

jp1924 commented May 27, 2026

Copy link
Copy Markdown
Contributor Author

@vasqu @bigshanedogg @zucchini-nlp

Sorry for the late reply.
I agree with your suggestions.
The first suggestion has been reflected in the code.
The third suggestion will be handled on the hub side, so I've removed the related note from the docs in advance.
Regarding the chat_template, @bigshanedogg — I'll remove it from the docs once we've had further discussion and the final fix is in.

@jp1924 jp1924 requested review from bigshanedogg and vasqu May 27, 2026 02:24
@vasqu

vasqu commented May 28, 2026

Copy link
Copy Markdown
Contributor

Did I understand it correctly that the template fixes are still missing then? @bigshanedogg @jp1924

Would it be possible to make them available (through a hub PR for example). The goal is to split the image to separate image and video tokens / placeholders. Would like to review when we have everything together if that's ok

@bigshanedogg

Copy link
Copy Markdown
Contributor

Sure — here's my proposed breakdown and ordering of the work:

  1. Template fix on the hub@bigshanedogg
  2. Add the hyperclovax_vision_v2 processor@bigshanedogg
    • qwen2_vl is the reference; we'd add processing_hyperclovax_vision_v2.py following the same structure
  3. Update the related docs and validate@jp1924
  4. (Optional) Benchmark validation tests@bigshanedogg
  5. Final review@vasqu , @zucchini-nlp

I was thinking we could proceed roughly like this: once 1) and 2) are done, I'll share the hub PR here.
@jp1924 can then pick up 3) based on that, and once that's wrapped up we can move to the final review in 5).
Let me know if this works for you.

Also, I saw your comment from yesterday but wasn't able to get to it today.
That said, since I had already started on the processor-related work in advance,
I should be able to wrap up 1) and 2) by the end of the weekend and share the PR with you then.

@vasqu

vasqu commented May 28, 2026

Copy link
Copy Markdown
Contributor

Awesome, sounds good to me! Thanks a lot for all the work and quick responses, appreciate it

@jp1924

jp1924 commented May 28, 2026

Copy link
Copy Markdown
Contributor Author

@bigshanedogg
If I understand correctly,

  1. you modify the chat-template.jinja file in the hub,
  2. and configure the image and video processors in the hub to use hyperclovax_vision_v2.
    Since the model_type will change to hyperclovax_vision_v2 during this process,
  3. I’ll finish the work on the transformers based on this,
  4. After verifying performance based on the current code,
  5. Final review

Is that what you’re saying?
OK, got it.

@bigshanedogg

Copy link
Copy Markdown
Contributor

Thanks for summarizing — your understanding is largely correct!

3, 4, and 5 are exactly as you described. For 1 and 2, I'd just like to align on a couple of small details:

  1. The hub-side updates involve both config.json (the model_type field) and chat_template.jinja. Just wanted to call out config.json explicitly so it's clearly on our radar alongside the template fix.

  2. The processor changes will land both on the hub and in this branch.

As for where to commit the processor changes

  • A. either directly to your jp1924:feat/hcx-seed-32b branch, or
  • B. via a separate branch merged into this PR
    I'd be happy to defer to @jp1924 and @vasqu on this.

If it helps, my own thinking was to commit directly to this branch, since the processor additions naturally move together with the model code, and keeping things in a single branch might be a bit easier to track given everything else the reviewers are juggling.
But I'm equally happy to go with whichever flow works best for you both — please let me know what you'd prefer.

@jp1924

jp1924 commented May 29, 2026

Copy link
Copy Markdown
Contributor Author

@bigshanedogg
Got it, I understand option 1.

As for option 2, regardless of the exact approach, it basically means restoring the video and image processors that were previously removed as duplicates during this PR, right?
And since the video/image processor work is already in progress anyway, I’m good with going that route.

Yeah, let’s proceed like that. You can either open a PR against jp1924:feat/hcx-seed-32b, send it as a code suggestion (not sure if that’ll work here though), or upload it to the hub and I can commit/apply it on my side.

Since this means adding more code changes around the video/image processors, I think there are probably two scenarios:

  1. You make the implementation polished enough that reviewers won’t have much to comment on, or
  2. After merge, I’ll handle follow-up changes based on reviewer feedback.

Either way, please understand that I may need to touch up some parts of the code afterward depending on review comments.

Since this involves some additional implementation work, the PR will probably get delayed a bit more.
But looking at the hub, I saw one PR with 596 comments that stayed open for 8 months lol.
Compared to that, we’re still doing fine 😂

I’ve also been pretty busy lately, so I couldn’t spend much time on this PR and my replies were slower than usual.
Things have calmed down a bit now though, so I should be able to help get this wrapped up faster.

@github-actions

Copy link
Copy Markdown
Contributor

[For maintainers] Suggested jobs to run (before merge)

run-slow: auto, hyperclovax_vision_v2, qwen2_5_vl

@vasqu

vasqu commented May 29, 2026

Copy link
Copy Markdown
Contributor

So I see we are going for option 2? But yea fine with either way tbh, just a matter of preference for you guys to sync 🤗

@jp1924

jp1924 commented May 29, 2026

Copy link
Copy Markdown
Contributor Author

Yeah, looks like I'll go with Option 2. I'll send another review request once the work is done!

@bigshanedogg

bigshanedogg commented Jun 1, 2026

Copy link
Copy Markdown
Contributor

Sharing a quick progress update since things are running a bit behind.

Status

  • 1) Hub-side updates: config.json, chat_template.jinja, removal of the .py files, and preprocessor_config.json adjustments to align with the upstream processor.
  • 2) Processor changes for this PR: split processing_*.py into processing_*.py / image_processing_*.py / video_processing_*.py, plus auto mapping updates. (Logic-side work is complete; only the style/lint pass with make fix-repo remains.)
  • 🔄 4) (Optional) Benchmark validation tests

What's blocking

A quick sanity check on our side suggests the current state doesn't fully reproduce our released performanceAI2D_test is around 65 vs. the expected 85+.
This isn't a conclusive result though; it was a quick first pass, so I may have missed something and I'm re-verifying now.
This is what I've looked into so far:

  • ✅ Processor outputs (pixel_values, etc.) compared — no issue on the first pass.
  • 🔄 Comparing intermediate tensors stage by stage (e.g., post-VE, post-VisionMLP, etc.).

@jp1924, if you happen to have any prior sanity-check results or notes from your side, I'd love to cross-reference them — it might well be a small processor-side issue I'm overlooking, or a minor cause like a dtype mismatch that sometimes pops up.
Your input would help me narrow things down faster.

Path forward

Given @jp1924's earlier concern about not dragging this PR out, one option is to merge as-is and let me submit a follow-up fix PR once we've found the root cause.
If you'd prefer to land the fix here, I can open a PR against jp1924:feat/hcx-seed-32b with the processor changes in the meantime.
(Side note: I noticed jp1924/transformers doesn't currently appear as a selectable base repository on my end, or if I'm just missing something.)

Either way works for me — please let me know what would prefer 🙏

@vasqu

vasqu commented Jun 1, 2026

Copy link
Copy Markdown
Contributor

I'm fine with either way, we can also fix afterwards but best would be to have aligned outputs tbh - except we are really in a time rush. Correctness > quickness imo

selectable base repository --> it might be because you created your changes based on the transformers base not the fork? Either way, @jp1924 could add your branch as remote and add a PR based on that I think OR you could be added as collaborator so you can "sync" it to the fork there and open a PR that way.

@jp1924

jp1924 commented Jun 1, 2026

Copy link
Copy Markdown
Contributor Author

@bigshanedogg
This is an evaluation I conducted a while back. I simply used KoBEST, which is based on log-likelihood, for the evaluation.
#44314 (comment)

I used to be against PRs getting too long, but after seeing the PRs for the “Add model” features open on the Transformers GitHub, I’ve had a change of heart—it’s totally fine now, lol.
Also, as @vasqu mentioned, I think it’s better to release the feature in a stable state rather than in an incomplete one.

Hmm... What kind of evaluation are you currently conducting?
Could you share the evaluation results and the environment with me? I’ll take a look on my end as well.

@bigshanedogg

bigshanedogg commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

@jp1924,
I agree with you that ideally we'd want to resolve the reproducibility question before release.
I'll re-check my own evaluation process first to rule out any mistakes on my side, and if a real fix to the model code is needed, I'll prepare a PR against this branch.

Sharing a few details below for context and to keep us in sync:

This is an evaluation I conducted a while back. I simply used KoBEST, which is based on log-likelihood, for the evaluation.

Since the 32B uses the bare LM class, the KoBEST result isn't unrelated — but as it's a bare-LM evaluation, it is not sufficient on its own to validate this PR, where we'd want an end-to-end VLM benchmark.

What kind of evaluation are you currently conducting?

The evaluation I'm running is essentially the lmms-eval-based VLM evaluation that you mentioned in #44314 (comment) hadn't been completed yet.
So if you're open to cross-checking together, it can be seen as a continuation of that earlier effort.

I attempted evaluation using evolvinglmms-lab/lmms-eval with NCSOFT/K-MMStar, but encountered errors during the lmms-eval preprocessing pipeline due to differences in chat template handling compared to standard VLMs.

For the chat template issue, two options should work:

  1. Use the revision parameter pointing to the Hub-side update I shared in the previous comment.
  2. Download the checkpoint locally, modify chat_template.jinja as needed, and load it via from_pretrained() with the local path.

The second approach in particular should let you freely adjust the checkpoint, so the limitation you ran into shouldn't be a blocker.

Also, a quick note on benchmark choice: K-MMStar is a fine choice, but for comparison with the Tech Report numbers, K-MMBench, K-DTCBench, or TextVQA would probably be more aligned.
Llava-W tends to be noisy due to its llm-as-a-judge nature, and SeedBench has a large sample count so it takes quite a while to run.
I started with AI2D_test simply because it's the fastest to run — I'm planning to validate against the benchmarks above as well.

Could you share the evaluation results and the environment with me?

If the target VLM in lmms-eval is adapted to load HyperCLOVAX-SEED-Think-32B via the transformers code in this PR, the evaluation should be equivalent — the underlying metric shouldn't differ between tools.
For full transparency: my evaluation is run through an internal tool that we used to measure the numbers reported in the Tech Report, so I'm not able to share the environment itself.
(For the evaluation results, please refer to the AI2D_test numbers and the numbers from Tech report I shared above.)

@jp1924

jp1924 commented Jun 5, 2026

Copy link
Copy Markdown
Contributor Author

@bigshanedogg
Yeah, sounds good. I'll give that a shot and see how it goes.

By the way, if the processor changes you worked on are already done on your side, could you send over a PR for those first?

We're already validating things anyway, so there's no reason not to get the processor review started in parallel. Anything we can get reviewed and out of the way early, let's just get it done and keep things moving.

Oh, and could you also take a look at the PR I uploaded to the Hub and get that merged when you get a chance?

At this point we've been going back and forth on this for quite a while, so it'd be pretty cool if I could become a contributor to your repo too 😂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants