Log file Viewer
#pypa-dev logs for Saturday the 22nd of February, 2020
[00:00:09] <techalchemy> well you push your code to version control, and usually the next thing you want is to build it
[00:00:34] <techalchemy> i dont think anyone planned to build build systems into vcs but they naturally kind of melded together
[00:01:34] <tos9> yeah I mean... the next thing you do is deploy it, so presumably gitlab grows a fanning deployment thing, and then I guess after that you monitor it so prob it needs a metric aggregation platform
[00:04:36] <techalchemy> i mean you can store your code or you can store it and also have something to automatically let you push it somewhere when you're done working on it
[00:05:46] <techalchemy> sometimes it needs to be built / tested before everyone can agree it's good, a lot of the time while you're deciding if you want to, say, merge changes (who knew you'd want a diff viewer in your vcs) (why would you want to comment on a diff) (what is a merge anyway, you just apply patches right?)
[00:06:14] <techalchemy> anyhow as part of deciding if you want to merge changes sometimes you want to know if the changes, for example, break stuff
[00:07:07] <techalchemy> sure you can pull the branch yourself and run the tests and hopefully you did that in a clean environment, but you can also integrate the testing with your VCS and have it just show you as part of your review experience whether the changes you're reviewing actually break things
[00:07:32] <techalchemy> that usually requires building, so that's probably why there's a build system
[00:12:11] <tos9> I don't see how doing that in the same tool can ever be better than separately though -- the only real angle there would be to lock you in, or more positively "better integrate"
[00:12:25] <tos9> 2 tools are to me always better with one, because now they can be used separately even if you're not using gitlab for your vcs
[00:12:57] <tos9> so if you're going to write a new build system, there doesn't seem to be a good reason to write it inside some other tool from another part of the process -- sure you may want to *view* their results in your existing tool
[00:13:33] <tos9> of course GH did the same thing and built their build tool straight into their VCS platform
[00:14:17] <tos9> I hope you wouldn't argue GHA wouldn't be better if it were a self contained service you could use even if you weren't hosting code in GH?
[00:15:41] <mrpackethead86> I am making really good use of codepipelines in AWS.. Its really very powerful and can integrate many differnet tools togehter.
[00:17:44] <mrpackethead86> My pipelines can often end up producing a python package, and publishing that to a PyPi repo
[00:18:09] <mrpackethead86> and other pipelines, end up using those packages as artifacts that end up in teh build process of another.
[00:26:51] <toad_polo> Their CI offering does seem pretty good, though, and Travis was deeply integrated with GL to start with, so it's kind of all bad.
[00:27:33] <toad_polo> Also the GL pipelines I wrote are basically docker files, so they're slightly more portable than they seem.
[13:50:41] <dustfinger> It would be nice to have a section called dev_require where packages that are not required during build but are things a developer might need or want installed for various reasons could be listed. Packages like autopep, mock, twine might go in this section.
[13:53:34] <dustfinger> Also, the section should be installable independently of local packages. The reason being is that I seldom want to install the package I am developing in the venv that contains the dependencies for the package under development. However; I would want to be able to install the dev_requires in that venv.
[13:55:40] <dustfinger> I know an option could be added to allow extra_requires to be installed independently of the local pcakges, but that would overload its semantics, so it makes more sense to have a new section for dev_requires. Thoughts?
[14:21:43] <toad_polo> The more general "install dependencies only" thing in pip seems like a fairly common use case.
[14:22:16] <toad_polo> I tend to put dev requirements in tox.ini these days, so I can separate them by the thing I'm trying to do.
[14:23:04] <toad_polo> But another common workflow that I like better than using extras is requirements-dev.txt
[14:26:03] <toad_polo> I'm not sure why people recommend it the other way, maybe to minimize proliferation of files?
[14:33:15] <dustfinger> toad_polo: that is a good idea. I like requirements-dev.txt solution. Not sure why I didn't think of that, but sometimes the mental filter is too agressive :-P
[14:35:14] <dustfinger> But yes, I can see why people might want to minimize the proliferation of files. It can be nice to see all the potential dependencies in one place, but I can live with this separation nad place dev type dependencies in a separate file.
[22:08:30] <travis-ci> Change view : https://github.com/pypa/twine/compare/efd0e4402c9f14c3b2ad3359c861a3112b8c6b36...e9d628c5764e24a1345eae0cf45486893d326fbb