devassistant (INACTIVE)

devassistant@lists.fedoraproject.org

35 discussions

RHEL 7 running DevAssistant 0.11.2
by David Kenner 05 Jan '18

05 Jan '18

I just downloaded and am trying to learn use devassistant. First I would like to see the GUI, but I am not sure of how to launch that. Can some one provide further instructions on launching the GUI. Any help is greatly appreciated

2 1

devassistant.org: OpenShift Online 2 ends soon
by Miro Hrončok 30 Aug '17

30 Aug '17

Hi, "After September 30th, 2017, Red Hat OpenShift Online 2 (our Free, Bronze, and Silver offerings in v2) will no longer be available." We can do one of the following: 1) nothing, the website will seize to exist 2) freeze the website to HTML (probably add a "dead project" header/warning) and host on GitHub pages or similar (loose HTTPS) 3) host somewhere else IMHO 3 is not worth it. I'm inclined to do 1 as it would send a strong message to potential users :D Thoughts? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

6 5

Golang support
by Szymon Notoja 08 Dec '16

08 Dec '16

Hello Are You going to suport golang in da? Cheers -- Szymon

2 1

RPG integration proposal
by Cibulka Miroslav 23 Oct '15

23 Oct '15

Greetings! We are finding a way how to integrate RPM package generation with devassistant project. RPG can be executed from Python API, can be extended by Python based plugin and is also GUI application that can user interact with. What would be the most feasible way to integrate the RPG functionality into devassitant? (rh-lab-q) RPG team

3 2

CI for important assistants
by Josef Stribny 16 Sep '15

16 Sep '15

Hi all, since we are preparing Fedora Developer Portal[0, testing instance] which will feature various assistants (language assistants, Vagrant assistant) I would like to make sure that they actually work and are up-to-date. E.g. we mention Ruby assistant for installing Rails that does not install right set of packages on Fedora 22[0]. Therefore it would be quite beneficial having tests/CI for those assistants (at least the important ones). Testing it manually is time-consuming and currently not done by anyone. And I think that's not acceptable for the future especially if DevAssistant gets such a big promotion in almost any content on the Fedora Developer Portal. Ideas how to solve it? Best Regards Josef [0] http://developer.fedorainfracloud.org/ [1] https://github.com/developer-portal/content/blob/master/tech/languages/ruby…

4 3

DevAssistant Client/Server—Resulting Architecture
by Tomas Radej 15 Sep '15

15 Sep '15

Howdy, all friends of DevAssistant. After a thorough deliberation and countless meetings, we have established how the final layout of DevAssistant will look like. It will be much simpler than my original suggestion from April [1], allowing only one instance of the DA server running at a time on one machine, but the security or backwards compatibility with existing assistants will not be compromised. The core of the design is the server, which will be a simple service containing the current DA logic, listening on a UNIX socket (in case you're running DA locally) or a web socket (for when the Server is in a container, a virtual machine, or even a remote machine). By connecting to that socket, a client will be able to communicate with the server through a JSON API. This API is in the works, and will cater to all sorts of clients—CLI, GUI, Web, plugins for IDEs etc.—while staying sane, i. e. the CLI client will be able to request detailed info of an assistant without receiving a PNG icon with it. On the other hand, a GUI client will make good use of it. The specification of the first version of the API will be out in a matter of days, so stay tuned. Bear in mind, though, that if you run DA remotely, the server will only be able to modify the environment of the remote machine, and not the one where the client is running, unless it's exactly the same machine. You'll then have to mount a filesystem on the host into the guest if you want to do that, and in some cases (like running DA in a container), installing dependencies won't make all that much sense unless you commit the container. For Fedora 24, we'd like to have two clients that can work with the server described above: a CLI and a web client. The Web client will be a tiny webserver whose only function will be translating API calls into pretty HTML and CSS, so that you can work with it like you did with the original GTK-based GUI. We have planned to redesign the GUI for some time, and the time is now. Running "da-gui" will then open your default browser pointed to localhost:port where the web app will reside. On top of that, when the time comes, we'd like to have a couple IDE plugins, like for Eclipse or other, but at the moment we don't have the time and manpower to make that happen. Of course, the client/server transition has security implications. We already have concrete solutions for some use cases and an outline for others. In local deployment, the immediate communication between the server and clients will be made through a UNIX socket, which is basically a special kind of file. With DA, only the current user will be granted permissions to the file, making a outside attack unlikely. We're also considering using SELinux for added security even in the context of a single user. For the web client, we'll most likely use TLS. If the clients connect to the remote server (in a container, VM etc.), TLS is in any case a must. Even with this general direction set, we welcome feedback and critique so that we can make DevAssistant more useful for all of us in the community, so please let us know if you think something could be done better or if you want to do it :) . Cheers, Tomas [1] https://lists.fedoraproject.org/pipermail/devassistant/2015-April/000065.ht… -- Tomas Radej

5 4

Thanks for DevAssistant!
by Nick Coghlan 25 Aug '15

25 Aug '15

Since I just sent a number of suggestions for possible UX improvement to the GitHub issue tracker after setting up a new Django project, I wanted to post this to say "thanks" explicitly - working through the DA UI is already a significant improvement over doing things manually! Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

2 1

We Should Refactor "prep custom"
by Tomas Radej 23 Jun '15

23 Jun '15

Hi, all. »TL;DR available below« As DevAssistant gains popularity, it is increasingly used by it's target group - developers. Developers like things that just work, and hate reading the manual. As it happens, with DevAssistant, you often need to read the manual to understand what's going on, and I'd like to change that. Today, I'd like to talk about the "prep custom" assistant. It is one of the most versatile assistants out there, mainly because it can clone out any repo you want, and even automatically fork it on GitHub if you want. However, it is also one of the least discoverable assistants because people don't know what "custom" means. There are two key issues with the assistant that I have identified: 1) The assistant's name is not intuitive 2) It offers a lot of GitHub functionality, but isn't named after GitHub Let's start with point 2: I have got multiple complaints from people who tried to check out a GitHub repo by running 'da twk github' or the like, because what they wanted to do is check out a GitHub repo. When talking about DevAssistant at conferences and online, we stress that DevAssistant is pretty damn good with GitHub, so it makes sense to have a GitHub assistant, right? But we don't have one. I suggest we do, and name it "prep github". It would use the USERNAME/REPONAME positional argument, and also offer the --gh-fork functionality. The mechanics of the github assistant should be the identical to current "prep custom", i. e. check out the repo and try running the .devassistant file with the user's permission. The "prep custom" assistant would then be named "prep repo", and would only take the URL as an argument (and path where to put the directory, of course). It would initially support only git, but could support e. g. mercurial or even svn in the future (the correct binary can be guessed from the URL or by trial and error). TL;DR: the "prep custom" assistant should be removed and replaced by assistants that look like this: $ da prep github USERNAME/REPONAME [-s,--ssh] [-f,--gh-fork [USERNAME]] [-p,--path PATH] $ da prep repo URL [-p,--path PATH] Both assistants check out the git repo, look for /.devassistant and execute it if the user wishes so. The "prep repo" assistant supports git for now, but is extensible for hg or svn too. So, what do you think? -- Tomas Radej

3 2

Distributing Assistants with Upstream Code
by Tomas Radej 23 Jun '15

23 Jun '15

Hello everyone. Since DevAssistant is about to undergo some major changes (see [1] for details), I think it would be great to factor in some additional changes that could make working with DevAssistant even easier than it's now. For this reason, I'd like to propose another change to the DevAssistant workflow: storing assistants directly in upstream repositories with the code they're supposed to work with. Both myself and Slavek have encouraged developers to create their own assistants and distribute them in the form of DAP archives. This approach has caught on quite well for general purpose assistants, like those for Gnome apps, Vala, or Android SDK [2]. However, we learnt that developers don't like this format for distributing assistants used with their particular projects. What I suggest is hearing out the #1 suggestion of the users themselves: make it possible to include assistants in the repos they're meant for. There are a few issues with this approach (talking about those that I identified. I'm sure you'll find more). The main one is that DevAssistant is currently stateless, meaning it doesn't remember anything between invocations (except for some configs stored in ~/.devassistant/config). To work with these assistants, which aren't installed in a path recognized by DA, I believe it's necessary to introduce a new functionality; let's call it "da open". When "opening" a directory, DevAssistant would load assistants stored in that directory (more about that below). These assistants would be unloaded by running "da close". Remembering which directory is "open" would be straightforward in the client/server architecture described in the mail linked at [1] - the server would run continuously, remembering which folders are open for the particular session. In addition to storing assistants with upstream code, users of DevAssistant would benefit from storing metadata about their project in a standardized format, in a file that would also point to the directory with the assistants. The reason for explicitly selecting the directory is that if you develop another set of assistants (probably a new DAP), loading everything in the directory would pick up even the unfinished assistants you're working on. I believe it's better to let the user load them only if they really mean to. To avoid reinventing the wheel for the millionth time, DevAssistant should use a standard metadata file that's also used by some other platform. I have looked around, and I believe I found a suitable solution in the form of the Nulecule specification [3], a predominantly container-based spec that is used with Project Atomic. This spec is not strict in its evaluation, leaving DevAssistant with almost unlimited manœuvering space as far as the metadata format goes, and be used for many generally useful tags, like author, homepage etc. A sample file in the Nulecule format would look, for example, like this: --- specversion: 0.0.2 id: mydjango-app metadata: name: My Django App appversion: 0.0.1dev license: name: GNU GPL v2 or later url: https://www.gnu.org/licenses/gpl-2.0.html authors: [ 'Tomas Radej <tradej(a)redhat.com>' ] homepage: https://example.com/mydjangoapp devassistant: assistants: /assistants minversion: 1.0a tags: [ atomic, python, django ] graph: - name: mydjango-app --- The "graph" field is there because the Nulecule spec mandates it. For non-Atomic apps, it isn't important. In the "metadata > devassistant" field, the location of assistants would be stored, along with a minimal version of DevAssistant that is supported by the project, and tags indicating what kind of assistants can work with this project. I expect these tags to be a full replacement for the "Project Type" field currently present in .devassistant files, but not used anywhere. Assistants would then feature a field called "tag" or "project type" that would be matched against the tags in the metadata file upon running "da open", and then presented more prominently than unrelated assistants in the GUI and/or bash completion in the CLI. More fields can be introduced as necessary. What do you think? Is there an issue I missed, is this good, or is it absolute rubbish? Don't hesitate to criticise. Thanks, Tomas [1] DevAssistant Mailing List: https://lists.fedoraproject.org/pipermail/devassistant/2015-April/000065.ht… [2] DevAssistant Package Index: https://dapi.devassistant.org/ [3] Nulecule GitHub repo: https://github.com/projectatomic/nulecule

3 2

Going client/server
by Tomas Radej 03 Jun '15

03 Jun '15

Greetings, friends of all things DevAssistant. For eleven minor versions, DevAssistant has been the tool to set up your environment on your host system, on bare metal. That works very well, but an increasing number of developers can't use it for their use case. Why, you ask? Containers. While DevAssistant has very basic support for containers in the 'Docker' assistant, it still does all the magic on the host. What we need is a full-fledged containerised app support, and DevAssistant will have to change quite fundamentally to offer it. Right now, DevAssistant is pretty much a monolithic application that runs on the host machine, requires GTK+ for its GUI and makes some assumptions about what the environment looks like. That makes it quite hard to make it work reliably under Mac OS X or Windows, heck even different Linux distros. To overcome this problem, I suggest splitting DevAssistant based on the client/server architecture. The basic idea is that the server runs in a privileged container or on the host system, and very thin client connects to it and exchange information about assistants and commands through an API (for example using JSON). You may think about it as "DevAssistant as a service". When developing this architecture, I have heavily borrowed from Cockpit, the web-based sysadmin tool developed for Fedora, which uses a webserver to accept commands, and then, through a bridge app, issues calls to various system services. DevAssistant then should be reorganised into these components: The client ---------- While DevAssistant uses already a sort of a client-server architecture, the clients are still quite thick, and not easily replaceable. Our intention is to put only the bare minimum into the client - an engine to construct a user interface from the received data. That means that the command line interface will construct a help message with assistants and commands based on what is available on the server side. Similarly, the WebUI will construct a form based on fields that the server sends to it, generated from the arguments specified in an assistant. The client always runs under the user that wishes to run an assistant. I am acutely aware of the fact that by using the web interface for running commands under the root user, I am effectively delegating the security to the browser, but I doubt we currently have the resources to have a new full-fledged GUI based on some desktop graphical toolkit. The webserver ------------- The webserver is the front-facing part of the entire server, which interacts with the client. What it does is spin up a "bridge" instance (see below) for the user under whom the "client" is running, and pass messages between the two. The webserver itself doesn't touch the system or containers in any way, and will probably run under a unique user, for example 'devassistant'. I expect it will take the list of available users from /etc/passwd. I still don't know what webserver to use, but security is definitely what we should look at first. The bridge ---------- This is the core part of the new system, which will contain most of today's DevAssistant package. This part runs under the user who actually wants to execute the assistants, and is spawned by the webserver. It loads the available assistants, runs them with parameters supplied through the webserver, and if necessary, delegates the execution of superuser tasks to the "service" with elevated privileges. The service ----------- Since the bridge runs under a user that doesn't necessarily have all the permissions an assistant may require, there will be a service (DBus?) that accepts commands and executes them as the super user. When such a command is invoked, the service will ask an authentication agent if the user is authorised to perform such a command, and based on the agent's reply will carry it out appropriately. If an additional authentication is required, the bridge sends a request to the client for proper authentication. The agent --------- The last part of the system is an authentication agent. This agent, based on its policies, decides if a given user is permitted to carry out a command passed to the "service", and return a True/False reply. This will probably be a PolicyKit service. This is the general plan of remodelling DevAssistant to better suit containerised development. I would like to know your ideas about or criticisms of this outline, as it may shape the development for months or years to come. Cheers, Tomas Radej

3 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

devassistant (INACTIVE)