Quoting Eli Schwartz via aur-general (2018-11-15 00:52:50) > On 11/14/18 11:50 PM, Daniel M. Capella via aur-general wrote: > > Quoting Levente Polyak via aur-general (2018-11-14 17:00:38) > >> - tests are awesome <3 run them whenever possible! more is better! > >> pulling sources from github is favorable when you get free tests > >> and sometimes manpages/docs > > > > Will work with the upstreams to distribute these. I prefer to use published > > offerings as they are what the authors intend to be used. GitHub > > autogenerated > > tarballs are also subject to change: > > https://marc.info/?l=openbsd-ports&m=151973450514279&w=2 > > I've seen the occasional *claim* that this happens, but I've yet to see > any actual case where this happens and it isn't because of upstream > force-pushing a tag. > > GitHub is supposed to use git-archive(1) for this, which is guaranteed > to be reproducible when generating .tar, although in theory > post-filtering this through a compressor like gzip can result in changes > from one version of git to another. I say in theory because I don't > recall this ever happening, and git-archive uses the fairly boring defaults. > > I don't see any reason to use substandard sources in order to avoid > checksum problems I don't believe in.
"substandard" 🤔 https://wiki.archlinux.org/index.php/Python_package_guidelines#Source > > For Rust sources there's also this problem: > > https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries > > > > Crates explicitly filter out lock files. `publish-lockfile` for binary > > crates > > is still only available in Cargo nightly. Communication is already in > > progress with the relevant upstreams. > > I have no clue what this is even supposed to mean. I'm reading your link > and it says that "it's conventional" for upstream developers of rust > applications to commit their lockfiles to git, but not to do so for > libraries. Given that one builds applications, and not libraries, I'm > unsure what the problem is here. > > Do you mean to say that crates.io doesn't ship all the files available > in git? Okay, I agree that git is the superior source. I don't generally > trust "intelligent" tools to decide what's important. > > Still not sure what this doc describing the split between libraries and > binaries, has to do with anything. https://github.com/bluejekyll/trust-dns/issues/604#issuecomment-436510626 > >> python-soco: > >> - there are tests available for check() via py.test > > > > Requires jumping through hoops. See the note: > > https://soco.readthedocs.io/en/latest/development/unittests.html?highlight=test#running-the-unit-tests > > Sounds like they have two sets of tests: some unittests for the code > correctness, plus unittests to test the interaction with an online server. > > Also sounds like the former, which are all we care about I suppose, > should be easy to do without any hoops, just by running pytest? Yeah, I tried that. > >> - do we _really_ need to split razer mouse tool UI and daemon here? > >> doubt it tbh. > > > > The UI is completely optional. ¯\_(ツ)_/¯ > > Why does this mean they cannot be a single package? > > -- > Eli Schwartz > Bug Wrangler and Trusted User > -- Best, polyzen
signature.asc
Description: signature