I have at work a bunch of derivations we are building in a large flake from all the internal repositories for these tools/packages.
Right now I’ve inlined into src the URL for each one at a particular commit.
Of course, updating them individually is a little tedious.
Should each one be a flake input URL? There could be 25+ URLs ?
Should I go back to niv inside my flake?
Yes, each URL should be defined in the inputs attributes so that they can be updated all at once. Their current revision will be saved in the file flake.lock.
is that crazy to just have hundreds in the start of my flake.nix file?
Seems excessive vs. in a separate JSON file or can I create them dynamically from a JSON file.
Perhaps this might help you ? GitHub - vic/flake-file: Generate flake.nix from module options.
Feel free to ask @vic if you need more info!
No. It blows up the flake.nix, your lockfile, and turns parallel fetching to serial.
npins/niv is also serial iirc (builtin fetchers always are). Maybe nvfetcher (which uses nixpkgs fetchers) would be decent?
Hey @fzakaria,
If you DO need those internal repos to be part of the flake manifest, then yes, flake-file can help you generate the flake.nix file from anything you can process with nix code (reading .nix, json, even using import-tree if you need to discover certain kind of files and generate inputs from them).
Pretty much depends on how you plan to manage dependencies.
For example, my dendrix project has references to many community repositories, however I decided that dendrix’ own flake should not depend on all of them (because maybe people will be only interested in the contents of one or two repos), so I used npins, so the repos are loaded like sources = import ./npins; and when people evaluate a single repository only that source will be fetched on their end. If they were all part of the flake, then just depending on dendrix would cause people to fetch everything. I’m just mentioning this as an example of when it does not help. NOTE: Dendrix is not depending on those repos as flakes, just as archives/collections of nix modules.
Flake dependencies (as opposed to npins, and friends) allow these dependencies to re-use common dependencies via follows and for large auto-generated flakes like yours, tools like allfollow can be handy to automatically flatten the dependency tree.
Hope this helps a bit, if you do have further questions, feel free to ask or open issues. 
if it helps you can put the inputs at the end of your flake.nix file as well.