Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom extractors #3

Open
Araq opened this issue Jun 9, 2023 · 6 comments
Open

Custom extractors #3

Araq opened this issue Jun 9, 2023 · 6 comments
Labels
enhancement New feature or request

Comments

@Araq
Copy link
Member

Araq commented Jun 9, 2023

The parser that process project.nimble is what I call an extractor. Custom extractors allow to extend this mechanism to cover other package managers, including ones for different programming languages. An extractor can be written in any programming language you like.

The entry in the configuration would look somewhat like:

"extractor": {"pattern": "requirements.txt", "language": "python", "parser": "<url to extension>", "resolver": "SemVer"}
@Araq Araq added the enhancement New feature or request label Jun 9, 2023
@elcritch
Copy link
Contributor

One piece I'm not sure about is where non-Nim dependencies should be added/defined.

Would it just be overloading the requires in the nimble file and adding it as another dep? That'd possibly bork Nimble compat. Is there another option I haven't thought of?

@Araq
Copy link
Member Author

Araq commented Jun 21, 2023

You would setup an extractor as a plugin and its tied to a filename. For example

"requirements.txt" -> Pip compatible parser
"Cargo.toml" -> Cargo compatible parser

etc.

@elcritch
Copy link
Contributor

Ok that makes sense for running the extractors. Would the extractors also be responsible for outputting a list of dependencies/repos then from a Nim project?

Alternatively would non-Nim projects be just another requires which when cloned has one of the available extractor files in the repo?

As an example let's say that you have a cmake dependency that needs to be built. Do we specify it in the nimble file, or do we create a CMakeList.txt file in the Nim project that can then be parsed? I sorta like the idea of saying in the Nimble file what the dependency is, however that'd break Nimble compatibility right?

@Araq
Copy link
Member Author

Araq commented Jun 21, 2023

Do we specify it in the nimble file, or do we create a CMakeList.txt file in the Nim project that can then be parsed?

Neither. You specify in the .nimble file the URL of the dependency and its version. In the dependency there is already the CMakeList.txt file and Atlas understands this is a build step. This works today but you need to enable the cmake plugin first. But currently you cannot declare in the .nimble file the requirement of this plugin.

@Araq
Copy link
Member Author

Araq commented Jun 21, 2023

And now I repeated the same mistake again. Talking about custom builders when the topic is custom extractors...

@elcritch
Copy link
Contributor

elcritch commented Jun 21, 2023

No worries on my end, it's a bit overloaded and I'm unsure if it's more of a builders or extractors issue. It's really neither?

But currently you cannot declare in the .nimble file the requirement of this plugin.

Ah so in the Nimble file, but some other DSL construct like foreignDep "github.com/opencv/opencv"? I'd imagine Nimble could be able to be patched to ignore them or let people use them in custom nimble tasks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants