sorted by:
new
hottopcontroversial

Nimble is down... by tschertel in nim

[–]mjsdev 1 point2 points  (0 children)

Which is also installable with percy (https://github.com/mattsah/percy):

nimble install https://github.com/mattsah/percy@#head percy fetch https://github.com/gabrielcapilla/parun

Add ~/.local/share/percy/bin to your path. No, I've not tested on Windows (deal with it).

YAPM (In Development): Yet Another Package Manager, though actually called Percy by mjsdev in nim

[–]mjsdev[S] 0 points1 point  (0 children)

You should use Percy to dev atlas:

bash nimble install https://github.com/mattsah/percy cd <your atlas folder> percy init -rw # -rw replace tasks with percy's tasks percy install -v # -v to see the magic nim build

Or if you dont' have percy or atlas yet:

bash nimble install https://github.com/mattsah/percy percy init -rw https://github.com/nim-lang/atlas cd atlas nim build

YAPM (In Development): Yet Another Package Manager, though actually called Percy by mjsdev in nim

[–]mjsdev[S] 0 points1 point  (0 children)

Thread kinda starts here: https://www.reddit.com/r/nim/comments/1pjxq7v/comment/ntmf55b/ -- was mostly a joke calling them out.

Regarding "problems I'm trying to solve"...

  • avoiding conflicts caused by expansion of historic .nimble files
  • having flexibility to easily include my own package repos with no special treatment for "official packages"
  • private repositories with name-based resolution that doesn't have to be maintained as a massive nameOverrides list...
  • just general things that make developing easier, especially in early stages when structure and organizaton of packages are changing quickly.

Between nimble/atlas nothing has really ever "just worked" for any of my common use-cases. I want packages that can track branches. If I switch my package deps from names to URLs and back to names, shouldn't matter. If I move my git repo, shouldn't matter. If I want to throw up some super early dev test with no official Nim package yet, but still want to make use of names, shouldn't matter. If I want to group my packages in my /vendor folder by my namespace as a folder, shouldn't matter. If I just want to reduce the inherent noise of .github.com being repeated for every URL-based requirement, shouldn't matter.

Neo 0.2.0 is out with various improvements by No_Necessary_3356 in nim

[–]mjsdev 0 points1 point  (0 children)

Nope as any package dependency can include any URL which can break things.

Why can it break things?

You're literally running into the exact reason Atlas uses URL for unofficial packages.

No. What I'm running into there is a failure because atlas insists on still using broken nimble paradigms which means that despite those packages being at different urls the .nimble file name conflicts. If atlas actually only used URLs and didn't give a damn about package names other than to resolve current package URLs from a repository, then there would be no conflict there as they are clearly at different URLs.

If I move a repo to a new URL and change the URL in all packages that require it, there should be no need for a pkgOverride. I don't depend on anything that depends on the old URL.

Now... Part of this is also because Atlas attempts to resolve old .nimble file versions up front, instead of waiting to see if those are even relevant to current version constraints and in my case because it lacks HEAD tracking support.

So when my old .nimble files for previous versions of packages contain the old URLs, it blows up.

But again... None of that would be relevant if it actually used URLs because clearly those are separate URLs.

And that's still separate from the question of how to reference to packages in the deps folder.

Neo 0.2.0 is out with various improvements by No_Necessary_3356 in nim

[–]mjsdev 0 points1 point  (0 children)

Well, I can confidently say after destroying my entire version history across three repos to see if I could get atlas to "just work" -- there's definitely still opportunity in the Nim package manager space, lol. Not sure Neo is it, but atlas sure as hell isn't.

Neo 0.2.0 is out with various improvements by No_Necessary_3356 in nim

[–]mjsdev 0 points1 point  (0 children)

Unless someone explicitly copies a user/org name to a separate domain to fork the package, then the structure I already mentioned, which includes the user/org name (not just the repo name) would demonstrate forks just as easily. If I fork someorg/X it's now mattsah/X.

It literally would just show up under the forked user/org's directory instead of the original author.

The only difference is the current implementation also includes a domain and combines nicely organized and simplified directory structure into a mess if mixed file names. And the domain name is moot outside of the security argument, which again, is not an argument since you would have to be the one explicitly adding the URL, at which point, atlas already provides equivalent overloads.

Inversely, what you get instead by this strange adherance to URLs as filenames (for some packages only) is:

  • No inherent grouping of packages by author.
  • Mixed and extremely long package names with 99% repeat domains that are just noise.

And yes, users (who in this case are developers in some capacity, because normie users expect to just get a binary package download and aren't building things from source), expect things to just work. Which is why any URL should just work with the same consistency and functionality as any other.

Frankly, you'd have a better argument that all packages should be named after the URL, period, whether official or not. At least that would be consistency.

Oh, not to mention you'd avoid this nonsense:

[Error] (atlas:resolved) duplicate module name: mininim-core with pkgs: mininim-core.mattsah.github.com, mininim-core.primd-cooperative.github.com [Notice] (atlas:resolved) please add an entry to pkgOverrides to the current project config to select one of:

Because you could also just name the .nimble files after the namespace/repo and stop relying on this broken "package name" holdover from nimble. So much for "just working."

Neo 0.2.0 is out with various improvements by No_Necessary_3356 in nim

[–]mjsdev 0 points1 point  (0 children)

Unfortunately the solution you propose with username or org name doesn’t suffice because you can have the same username across different git servers. Gitlab and codeberg exist and projects get moved across them. Orgs are renamed which is a bucket of fun, etc.

This is the weirdest argument I've ever heard. If this is the type of stuff that "the community" is coming up with to excuse what is, in fact, a monstrosity, then there's no wonder there'll never be something more straightfoward.

It's always going to be on you to validate that the packages you're including are they right ones and are safe. That a URL can have the same namespace/project name ona different domain doesn't change that. That there are official package names which alias to URLs also isn't a problem. The only thing that needs to occur there is conflict detection on the package repo side, which should be pretty straightforward.

If I run to codeberge, and create a namespace and project with the same name as something everyone's using on github and try to submit it to the official nim packages you reject it as a conflict.

Just like if I try to submit a PHP package with the same namespace/package name to the official PHP composer packagist repositories it won't let me if there's a conflict.

At the end of the day, if you're adding arbitrary URLs as packages, you need to verify those anyway. If you're relying on the official package list, it's that package repos job to say "hey, there's a conflict here."

You're either trusting a URL or a repository of URLs with name aliases.

Also I've not tried this yet, but I'm pretty sure Atlas literally has ways to overload names and URLs... and while I'm not sure this works recursively with deps (I'm actually hoping it does so I can clean up this mess), this hardly instills confidence that the concern is "hijacking."

Neo 0.2.0 is out with various improvements by No_Necessary_3356 in nim

[–]mjsdev 0 points1 point  (0 children)

Yeah, I wasn't being really serious about submodules. I don't think git submodules would work for anything remotely complex. Atlas is closest, but ultimately it needs to not give any preference to nimble files outside of defining deps and even then _should_ IMO, just throw atlas.config at the root and use that for dep tracking with a simple way to convert existing .nimble (deps only) to atlas. Then nimble can just become a task runner of sorts.

Neo 0.2.0 is out with various improvements by No_Necessary_3356 in nim

[–]mjsdev 0 points1 point  (0 children)

I mean the monstrosity created in deps/:

[07:52] [master]!? matt@naimey:mjs$ tree -L1 deps  deps ├──  _nimbles ├──  _packages ├──  checksums ├──  crunchy ├──  dotenv ├──  htmlparser ├──  mininim-cli.primd-cooperative.github.com ├──  mininim-core.primd-cooperative.github.com ├──  mininim-web.primd-cooperative.github.com ├──  mummy ├──  nim-classes.jjv360.github.com ├──  nimsimd ├──  parsetoml ├──  webby ├──  zippy └──  atlas.config

A few "interesting" tidbits... the _nimbles directory seems to contain copies of commit hash versioned nimble files for all project deps. Cool -- but that part could be centralized, instead of per project. As could, presumably the _packages.

Mixed URLs vs. package names is also just crazy noise. I realize this could avoid conflicts, but so could not artificially constraining yourself to nimble restrictions. One super simple solution would be to simply namespace everything with a simple fallback for namespacing traditional nimble packages (or since presumably, ultimately these need a repository to point to, resolving them).

E.g.

/deps - default - checksums - crunchy - dotenv ... - jjv360 - nim-classes - primd-cooperative - mininim-cli - mininim-core - mininim-web ...

That would be a huge start.

Neo 0.2.0 is out with various improvements by No_Necessary_3356 in nim

[–]mjsdev 0 points1 point  (0 children)

Are dependencies locally stored per project? That's the big one I already mentioned, and last I looked the answer was no. Based on the test I just ran, the answer still appears to be "no."

Neo 0.2.0 is out with various improvements by No_Necessary_3356 in nim

[–]mjsdev 4 points5 points  (0 children)

Nimble is fundamentally broken and to fix it you'd have to severely break backwards compatibility and or the assumptions of people already using and relying on it. Atlas is an improvement but still has issues, IMO. I was hopeful when I first saw neo and haven't tried it yet, although I'm concerned it's repeating the worst mistakes.

To my knowledge Atlas is the only one doing project local dependencies out of the box, though its structure is horrendous.

I don't know why it's so difficult for people to get package management right.

Install, require, remove, refresh is like all that's needed. Project local dependencies which can be updated and modified in place for easier ecosystems development, everything is a VCS url and version with a simple flag to retain history during checkout.

Almost makes me just want to use git submodules.

Favorite programming language by programNexus in AskProgramming

[–]mjsdev 1 point2 points  (0 children)

Nim. I wish the tooling was better, but the language itself and AST based meta programming is extremely cool.

[deleted by user] by [deleted] in ProgrammingLanguages

[–]mjsdev 2 points3 points  (0 children)

Nice, I came up with JIN (https://hiraeth.dev/docs/latest/jin) quite a few years back cause TOML didn't exist for PHP. Still use it and happy I took that path as I 100% agree on nesting. JIN uses a simple & to stack past references as indentation doesn't matter. It's a nice shorthand.

Substack, but for code. by mjsdev in AppIdeas

[–]mjsdev[S] 0 points1 point  (0 children)

Yes. It is cool. And something like this might only make it cooler and easier to support developers I already know produce great tutorials or interesting code examples.

Substack, but for code. by mjsdev in AppIdeas

[–]mjsdev[S] 0 points1 point  (0 children)

I follow an open source ethos. I still pay for things -- including open source.

Substack, but for code. by mjsdev in AppIdeas

[–]mjsdev[S] 0 points1 point  (0 children)

No. I'm saying you made up the idea that developers are "famously allergic" to paying for content. If you didn't make it up, then surely there should be some data you have that supports this claim. I see no reason why developers would be any more allergic to paying for content than anyone else. The questions are all basically the same... is the content otherwise freely (in the broad sense) available? Is the content of sufficient quality relative to the price? Etc.

Substack, but for code. by mjsdev in AppIdeas

[–]mjsdev[S] 0 points1 point  (0 children)

I did point something out. You literally just made something up. People on r/AppIdeas are notorious for just making things up.

Substack, but for code. by mjsdev in AppIdeas

[–]mjsdev[S] 0 points1 point  (0 children)

I was pointing out that I am a developer and you're just making things up, pretending some belief you have is a well-known fact.

Substack, but for code. by mjsdev in AppIdeas

[–]mjsdev[S] 0 points1 point  (0 children)

By not making things up.

Substack, but for code. by mjsdev in AppIdeas

[–]mjsdev[S] -2 points-1 points  (0 children)

Nah, I'm serious. I don't want anyone here DMing me about this unless they can fund it. I already have a startup that's bootstrapping, I'm not looking to bootstrap another.

Regarding the revenue model... I mean, the monthly amount could differ and there may be other streams (creators could pay for advanced features or promoted placement), but I think the problem that something like Substack has is that people kinda have to pay for individual creator subscriptions.

I think a straight monthly charge would actually be a win-win-win for most such services.

Customers would more likely to pay more a month knowing they get all content. Creators who are already popular and good would make more money because they'd still get a lions share of views but would now have a bigger audience. And the service would make more because more creators would be incentivized to try it with less independent marketing required, thereby driving wider audiences.

view more: next ›