Make the description a top-level flake attribute.

relates to https://github.com/flox/product/issues/16

floxEnvs currently do not support nested packages, and the current format for flox.nix is ambiguous, as there's no way to differentiate between:
A nested package: nixpkgs-flox.python3Packages.requests = { version = "1.12" };
and
A packge with configuration: nixpkgs-flox.VSCode.settings = { key = "value"; }

cc @tomberek

on both ubuntu 20.04 and fedora 35, when using the "default" template in floxpkgs public master branch, and flox 0.0.2-r193 we are seeing the following error when running flox develop

flox develop
[28.7 MiB DL] fetching Git repository 'ssh://[email protected]/flox/floxpkgs'Warning: Permanently added the ECDSA host key for IP address '140.82.113.3' to the list of known hosts.
warning: creating lock file '/home/floxdevbot/myproj/flake.lock'
trace: Not importing any attributes because the directory /nix/store/4s09qm10441a12wlgdp2wc0whs781jy0-source/pkgs/ doesn't exist
[2 copied (216.4 MiB), 92.0/65.9 MiB DL] downloading 'https://api.github.com/repos/DavHau/pyperror: The pypiDataRev seems to be older than the nixpkgs which is currently used.
       Because of this, mach-nix might lack dependency information for some python packages in nixpkgs.
       This can degrade the quality of the generated environment or result in failing builds.
       It is recommended to pass a newer pypiDataRev to mach-nix during import.
       For flakes users: Update the `pypi-deps-db` input of mach-nix.
       You can ignore this error by passing 'ignoreDataOutdated = true' to mk* or build* functions
(use '--show-trace' to show detailed location information)

Attempts to use the template result in complaints that evalCatalog does not contain etc-profiles.

Acceptance Criteria:

• The template must work "out of the box" for new users.

Per request of @ysndr

From the Nixpkgs manual: "The output hash of each dependency that uses a git source must be specified in the outputHashes attribute."

Ran into this with a user: https://floxtalk.slack.com/archives/C041FC8P41E/p1662495152447749

We should update the rust template as well as the Rust docs

Also ran into needing to add openssl.dev and darwin.apple_sdk.frameworks.SystemConfiguration to buildInputs.

After updating the floxpkgs version used to build managed environments (flox/flox#133) which starts using the builder introduced in #144 flox installs fail within the builder: https://github.com/flox/flox/actions/runs/5422480667/jobs/9861314816?pr=133#step:6:744

$ nix log /nix/store/z5445w1v9qp0y4zgk8rqjr8ilxwj0w1w-wrapper.drv

++ /nix/store/v6fpa3626msfmyg22pka0bzcsl49bdm0-perl-5.36.0/bin/perl -w /nix/store/sh2v88m6slc969vyvs7ysniwp53vs07n-builder.pl
warning: creating dangling symlink `/nix/store/q04paxp62wl547ax6s2rrkh6x3lxn5fj-wrapper//manifest.nix' -> `/nix/store/6y5ij59zczwgbs51zkzr7zs4ps6v9j2w-wrapper/manifest.nix' -> `unused'
error: not a directory: `/nix/store/szs36lz492gh28djg0710z2ni4vn60br-jq-1.6'
+ exitHandler
+ exitCode=2
+ set +e
+ '[' -n '' ']'
+ ((  2 != 0  ))
+ runHook failureHook
+ local hookName=failureHook
+ shift
+ local 'hooksSlice=failureHooks[@]'
+ local hook
+ for hook in "_callImplicitHook 0 $hookName" ${!hooksSlice+"${!hooksSlice}"}
+ _eval '_callImplicitHook 0 failureHook'
+ declare -F '_callImplicitHook 0 failureHook'
+ eval '_callImplicitHook 0 failureHook'
++ _callImplicitHook 0 failureHook
++ local def=0
++ local hookName=failureHook
++ declare -F failureHook
++ type -p failureHook
++ '[' -n '' ']'
++ return 0
+ return 0
+ '[' -n '' ']'
+ return 2

at what seems to be a missing built of jq

CAVEAT THIS IS A DRAFT THAT WILL BE CHANGING POSSIBLY DAILY AS INSIGHT IS INCORPORATED FROM OUR TEAM

PR

Functional tests per repo

A flox internal developer submits a PR to one of the main released branches where our product is already known to be in tested or working order

An automated test focusing only on the specific component functionality. These could be implemented in any way that accomplishes isolating the component being tested, so that failures are always originating only from the software being tested.

This is the only testing that should employ branch protection.

It is proposed that the flox/flox wrapper is a special case where branch protection does happen on PR, in order to assure that integrated function is actually working on the User Interface level.

Integration

A flox internal developer submits a PR to one of the main released branches where our product is already known to be in tested or working order

An automated test is kicked off using all of the latest released versions + the version the developer is submitting in the PR as a candidate to merge in.
The following 3 integration tests will be performed in all cases (these are subject to change by way of additions or changes as our software stack evolves)

A flox init test choosing the default template
A flox develop test
A test confirming the correct installation/versions of dependencies resulting from flox develop
A flox init test choosing the python-black template
A flox develop test
A set of tests confirming the function of python-black template

The automated testing suite will occur on a re-used machine to take advantage of previous cached builds.
If flox wrapper PR: The automated test will perform a build and use of flox wrapper to the target version running the above 3 tests, + an additional set of automated tests is triggered that will test all of the functions of the wrapper itself.

If flox/nix installers PR: a standalone test on an ephemeral machine that simply tests the install on the machine candidate, and confirms flox is installed. (this is effectively the installer matrix testing limited to testing the installers themselves).

If changes to floxpkgs-internal, floxpkgs public, or capacitor: Automated test will advance flake registry to the commit submitted in PR, and run the above integration tests.

A scheduled QA test
At least 3 times per week, a manual QA test on priority platforms is performed by Sam Rose (or whomever is responsible for QA testing of the product. These tests will cover all existing PR’s at the time of testing, plus the currently released to main release branches versions of the platform.
Current priority platforms consist of: ubuntu focal, mac os x aarch64/intel x86_64
Once per week QA testing will also be performed on: fedora 35, Arch linux, Nixos
Issue resulting from this QA test will be posted with explicit detail to respective issue queues for the components of software responsible for functionality
QA tester (Sam Rose) will report the status of this testing on a bi-weekly basis to the workplace product channel, and any other destination of Flox management’s choosing.

Hot fix

Please make QA/Sam Rose aware of hot fixes and he will perform a battery of tests ASAP to confirm these fixes across platforms.

https://github.com/flox/product/issues/16

related to https://github.com/flox/product/issues/16

Since we no longer recommend using flox.nix for project environments, we shouldn't create a flox.nix file when projects are created with flox init.